Type: Regression Bug
Affects Version/s: 7.0.X, Master
LPS-48559, we decided to OSGi-ify the Toolkits, requiring developers to deploy a hook that overrides the passwords.toolkit portal properties in order to use a different toolkit than the default. This already seems like a questionable decision since (1) All our Toolkits are in the portal core, (2) We have little to no documentation explaining how to write such a hook in DXP, and (3) This is substantially more work than what you had to do in previous versions of Liferay to achieve the same configuration. However, it's even worse than that, because even if you go to the trouble of writing such a hook and getting it to deploy properly... you'll find that the Toolkit you tried to register still doesn't get used. This is because, while your Toolkit does get registered by OSGi, it is in competition with the default PasswordPolicyToolkit, which was registered first, as it gets registered by the portal core. Since both service registrations are not assigned a service.ranking, OSGi selects the one that was registered first, which will always be the default PasswordPolicyToolkit. In short, you cannot use any Toolkit other than the PasswordPolicyToolkit.
Steps to Reproduce
1. Deploy the attached reg-exp-toolkit-hook.war file to Liferay.
2. Start up Liferay and log in as the admin user.
3. Attempt to change your password to something other than what it is currently.
Expected Result: Because of the properties set in the hook, your attempt should be unsuccessful, and the following message should be displayed in the UI:
That password does not comply with the regular expression (?=abcdefg). Please enter a different password.
Actual Result: The password is changed successfully.