The requirePassword configuration introduced in 6.1.0 asks for the old password when updating or deleting a user's credentials, but only if the requesting controller is not "security". Otherwise, admins couldn't update users, set passwords, etc.
Problem is: there are other Kuzzle API routes asking for credential deletions, mainly because the user itself is being deleted, and those calls should not be blocked.
So the logic has been slightly changed, and the protection now only affects API calls resulting from the auth controller, meaning that calls from the security controller, the admin one, or even from internal Kuzzle tasks are not blocked anymore.
Why a hotfix?
Because admin:loadSecurities first deletes existing users before loading the security fixtures, and because of this bug, user credentials are not deleted.
Kuzzle detects this and refuses to create a user if there are credentials existing on it: it handles that as a db inconsistency and bails out, which is intended and a good thing.
When Kuzzle is started with the --securities flag, because the admin:loadSecurities route fails, Kuzzle refuses to complete its start sequence and stops.
Description
The
requirePasswordconfiguration introduced in 6.1.0 asks for the old password when updating or deleting a user's credentials, but onlyif the requesting controller is not "security". Otherwise, admins couldn't update users, set passwords, etc.Problem is: there are other Kuzzle API routes asking for credential deletions, mainly because the user itself is being deleted, and those calls should not be blocked.
So the logic has been slightly changed, and the protection now only affects API calls resulting from the
authcontroller, meaning that calls from the security controller, the admin one, or even from internal Kuzzle tasks are not blocked anymore.Why a hotfix?
Because
admin:loadSecuritiesfirst deletes existing users before loading the security fixtures, and because of this bug, user credentials are not deleted. Kuzzle detects this and refuses to create a user if there are credentials existing on it: it handles that as a db inconsistency and bails out, which is intended and a good thing.When Kuzzle is started with the --securities flag, because the admin:loadSecurities route fails, Kuzzle refuses to complete its start sequence and stops.