[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