GitLab

For historical reasons, EncryptedPasswordMixin.setPassword was public and did its own security checks, this was the case since 7d0882ef ( setPassword have to do explicit security checks…, 2007-11-12), this was because we wanted to support cases where user can edit the login ("Edit portal content" permission), but not changed the password ("Set own password" permission).

Also, we wanted to support the case where login is edited through a view form, in that case we have a my_password field that is empty and we don't want to set the password to None in that case.

For these two reasons the API to set password was very complex and behaving differently from other accessors: usually setSomething(None) just set something to None, ie. "unset" something, but for passwords it was not the case. Also we had to introduce _forceSetPassword method, which sets the password without security checks, so that it can be called from unrestricted code for cases where user does not have the permission to reset password (like in the reset password scenario).

Since d1312cdb ( make edit check the security remove all useless security declaration on private method, 2008-05-23), edit supports restricted properties, so we can simplify all this and make setPassword a more standard accessor, ie:

• setPassword has a security declaration, so if it is called from restricted python the security will apply at __getattr__ time. edit method will also check security
• setPassword(None) reset the password.
• The logic to not change the password when editing in view mode is now edit responsability. ie. login.setPassword(None) resets, but login.edit(password=None) does not reset.

This also correct some usage of the lower level API (pw_encrypt and pw_validate) which were never supposed to use None:

• pw_validate was called with None when a user without password was trying to login, causing a TypeError that was cached by PAS and logged with level debug (and refusing login). Now the error is no longer raised.
• pw_encrypt was called with None (but apparently only in the tests, when doing user.newContent(portal_type='ERP5 Login', password=None)) and this was creating a login with password 'None' with AccessControl 2. With AccessControl 4 this was an Error.