[dev] [patch] for review - expiring passwords

[Jason M. Felice]

Chuck Hagenbuch wrote:

> 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.

Hmm...  A new page in services/ for changing password using $auth?  I 
like it.  Let me look and see if I'm not too lazy to do that now.

> - if you insist on sticking with passwd, then create an API method for it
> instead of doing the if (in_array('passwd' .... ) check.

OK.

> - "$changeReq = false)" - spell out the darn variable name :)

OK :)

>
> - 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?

get/setCredential() require the user to already be authenticated, and we 
need this in _authenticate()

> - 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.

It won't do any good public, since it will only be handled by login.php

> -chuck
>


-- 
 Jason M. Felice
 Cronosys, LLC <http://www.cronosys.com/>
 216.221.4600 x302