|
From: Christian B. <pos...@cb...> - 2007-10-09 00:10:43
|
Hello,
Am Sonntag, 7. Oktober 2007 schrieb David Goodwin:
> > > As these are the passwords for the admin user, how about we
> > > change is so admin passwords are _always_ encrypted with
> > > something decent? As admin passwords aren't used for mailboxes,
> > > it wouldn't have any impact outside of postfixadmin.
> >
> > Would be an idea. However, we'll need a way to handle existing
> > unencrypted passwords.
>
> That could be done through some sort of generic 'upgrade' script -
> which it appears we'll need....
Let's declare this problem minor when compared with database updates in
general ;-)
> > > My grievance with this is that when ever an admin is edited, I
> > > think your previous patch, implied that a users password had to
> > > be changed/set. Which is horrible.
> >
> > No, the password does not need to be touched. See my change in
> > r123:
>
> OK.
Will you commit this or shall I do it?
> > > If we're thinking of older ones, then we'd have to use
> > > something like PEAR::DB or PEAR::MDB2 - which emulate
> > > prepared-statement-ness.
> >
> > Ah, the old question of using an abstraction layer. I'm still not
> > sure if we really need it - but having some helper functions (for
> > example insert("table", array ("field1" => "value1", "field2" =>
> > "value2") that create database statements might be a good idea.
>
> Well, we could always bundle mdb2 / pear db with postfixadmin - this
> would remove any requirement for admins to set it up etc.
I'd like to split this to two questions:
a) do we want to use a database abstraction layer?
b) which one
a) Well, if there's a good and lightweight one available...
Let's sum up our database usage:
- INSERT and UPDATE queries
- DELETE queries
- SELECT queries with WHERE and LIMIT
- begin/end transaction
(did I miss something?)
So for me the question is if we need a full-featured abstraction layer
or only some simple functions that generate the query.
If the abstraction layer adds some hundred kB to the tarball, then we
need really good arguments for it IMHO ;-)
b) Good question...
Candidates are: (feel free to add missing ones)
- mdb2 (requires PEAR, together 420k as .tar.gz)
- pear db (http://pear.php.net/package/DB says it is obsolete and mdb2
should be used)
- adodb (470 kB .tar.gz) (proposed by Viktor Gotwig)
- adodb lite (370 kB .tar.gz)
- the S9Y (www.s9y.org) database routines, which are simple
(only 8 kB .tar.gz) but effective.
If you want to have a look at it:
http://php-blog.cvs.sourceforge.net/php-blog/serendipity/include/db/
Regards,
Christian Boltz
--
Fsck, I'm remembering back to the pre-archived-by-Google era of Usenet;
some local newbie was asking how to compile RM COBOL programs in the
Unix environment, and my anti-COBOL bias might have shown through as I
explained that the RM COBOL compiler on Unix was named "rm". [AdB]
|
