I want to implement a “change password” flow in UI Builder. A logged-in user should be able to change her current password. As a prerequisite, she must enter the currently valid password.
I found this previous post for this topic:
There, the solution proposed is to use the login API to verify the current password. My question:
Does the number of logins for this user pile up? So, if the user is changing her password 3 times, it is counted as 4! simultaneous logins?
Is it possible somehow to figure out how often a certain user is logged-in?
Yes, in that scenario the number of concurrent logins for a user will add up. There is no API to get the number of active logins per user. I will open an internal improvement ticket to provide the API to verify user’s password. The API will be restricted only to business logic (Cloud Code) for security reasons.
If the “old password” is correct, login works fine and the userObject is returned. Then, I’m changing the passwrd field in userObject to the new value and use the “Update User” block to change the password in the user database. At this point the code is running into an exception with the error
Error: Session timeout. Url: <https://eu-api.backendless.com/.../page/session_expiration/index.html>
at new ResponseError (sdk.js:14)
at checkStatus (sdk.js:14)
However, the password has been updated correctly in the database!
The last printed message is “Component toggeled!”. The email is not sent, so it seems that the Send Email block is causing the exception.
Just as a cross-test: if I’m replacing the block “set userObject to Login user …” with “set userObject to Get current user”, then the code runs through and the notification email is sent.
I believe the problem occurs because when the user’s password in the database is updated, the current user session (i.e. user-token) is invalidated. To circumvent the problem, try doing user login right after you update the user - that will refresh the user token in the app.
The user login is done as a workaround to check the validity of the current password, I.e. to prove the identity of the one who wants to change the password.
That’s why I don’t want to update the user DB with a new password before knowing that the right person is requesting the change.
I think a clean solution would be really an API that just validates the current password without side effects (as concluded above already)
