Page MenuHomePhabricator

Error if AuthPlugin autoCreate returns true and allowPasswordChange returns false
Closed, ResolvedPublic

Description

Author: mn12

Description:
If an implementation of AuthPlugin returns true from autoCreate, and false from
allowChangePassword, then an error results when attempting to create the new
record for a user who successfully authenticates for the first time.

The trace is essentially:

  1. (line 357 of SpecialUserlogin.php) The user has successfully authenticated

but has an id of 0 and the AuthPlugin implementation has returned true from
autoCreate so a call is made to initUser to create the new local user record.

  1. (line 311 of SpecialUserlogin.php) initUser calls setPassword on the user

object as part of initializing it before saving it to the local database.

  1. (line 1332 of User.php) setPassword checks the AuthPlugin implementation and

sees that allowPasswordChange returns false. Therefore it throws an error.

Scenario: We authenticate remotely against LDAP. Our users can only change
their password using a central facility outside of the Wiki. We want new
accounts to be created in our Wiki for any user who has succesfully
authenticated, but we do not want them to maintain a password in the local Wiki
database. Therefore we implemented autoCreate to return true and
allowPasswordChange to return false in our AuthPlugin subclass.

Possible resolution:
Only call setPassword from initUser conditionally based on the return value from
the AuthPlugin subclass' implementation of allowPasswordChange.


Version: 1.9.x
Severity: normal
Platform: PC

Details

Reference
bz9778

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:39 PM
bzimport set Reference to bz9778.
bzimport added a subscriber: Unknown Object (MLST).

Please test with 1.10.0rc1, as some behavior has changed:
Please note that the setPasswordInternal() function should be used to set the
password "internally" bypassing validity checks and the authentication backend.

  • This bug has been marked as a duplicate of 8815 ***