[dev] [patch] for review - expiring passwords
Chuck Hagenbuch
chuck at horde.org
Thu Jan 6 20:07:00 PST 2005
Quoting "Jason M. Felice" <jfelice at cronosys.com>:
> It's not done, but for sake of review on points of backwards
> compatibility and API changes, here's the patch I'm working on. I still
> have to:
>
> * Add auth driver methods to set expiration
> * Add configuration for default periods for expiration.
> * Have 'passwd' update the next password expiration.
> * Allow editing of expiration dates from user administration screen.
My suggestions/thoughts:
- don't bother with the passwd stuff; move password changing into the Auth
classes (like we've been wanting to do for a long time) while you're at it.
- if you insist on sticking with passwd, then create an API method for it
instead of doing the if (in_array('passwd' .... ) check.
- "$changeReq = false)" - spell out the darn variable name :)
- I know that an expiring password isn't really a credential, but the whole
thing would be a lot cleaner if you could just use the getCredential() /
setCredential() API to do this - maybe a passwordExpired credential?
- if you end up keeping it, I can think of a couple of reasons for making
requestPasswordChange() public - an app might expire a user, or what not. I
also think "isPasswordChangeRequested" is an unwieldy method name, but I'm not
coming up with anything appreciably better.
-chuck
--
"But she goes not abroad in search of monsters to destroy." - John
Quincy Adams
More information about the dev
mailing list