Timo Sirainen <[EMAIL PROTECTED]> writes: [...] > All of this forces that the checkpassword script developer either > handles the AUTHORIZED environment correctly or it doesn't work at > all. And it prevents admin from accidentally using the script wrong.
Ok, you convinced me that your concept has the advantage of forcing the checkpassword script author to try to implement all aspects of the spec. I'll implement it this way, as it isn't hard to do anyway. But I have to say, that I'm not really sure about the merits of trying to force other developers to do the right thing like this. The developer can still change the environment only when AUTHORIZED is set (why would he do something like that you ask? Maybe he did just copy and paste from a combined passdb and userdb checkpassword), the admin writing his own broken userdb checkpassword script still can use it for passdb, it only won't work for userdb (he will use prefetch until he finds the bug...). After all, nothing is foolproof to a sufficiently talented fool. ;-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
pgpRYyF9HtkJV.pgp
Description: PGP signature
