Joe Hardstaff:
What is the best way to allow a user to reset their password from within an app, that doesn’t include using the authForgot function?
I want the user to be able to set a new password during their onboarding but as the authReset needs a token, that is created through authForgot, not sure how we can do it without this.
Andrew Dam:
The authForgot is required to generate the token for the authReset.
You could in theory run a set of actions that calls the authForgot, run a hook that fetches the token that just got generated, pass it back to the front end, and trigger the authReset.
It’s not a standard practice; the usual way to allow the user to set their own password during onboarding would be to use the authRegister which would create the user in the helper file and tie that to some user record in your business file using a token.
If you share more on your authentication workflow, perhaps we could find a solution that works best for your use case.
Joe Hardstaff:
Thanks Andrew. Yes I appreciate that, however our app is not one whereby anyone can sign up. It will be used by organisations that handle adding users themselves, such as a manager or champion will add new staff. Then on that staff members first login they have to go through some onboarding steps, one of which would be to reset their password. The only way we can trigger that now is using a ‘forgot password’ type of approach, but they haven’t forgot their password, they just need to reset it.
I did try the above solution, calling the authForgot and fetch the token etc but it doesn’t seem to work.
Am I right in thinking then that anytime someone (in other apps) would want to reset their password, they would have to use the forgot password process (albeit it could be re-interfaced to look like a reset).
Andrew Dam:
That is correct, in the event that a user wishes to change their password, we would go through the forgot password process. This can definitely be re-interfaced to look more like a reset.
To address the initial question, we generally avoid manually creating users in the helper file to ensure the user’s passwords remain secure.
The best practice for the workflow you shared would be to have your managers/champions add users in your business file. These new users would have a token created and sent to them using a smart link with this token attached.
The users would be sent this link (usually through email) then go through your onboarding process and eventually enter a password that would trigger your authReset and create the user record in the helper file which would then allow them to log in.
If this workflow isn’t to your preference, we can definitely explore the other method of fetching the authReset token through a hook.
Joe Hardstaff:
That’s great Andrew. I did try and set users in our business file, but when I did this (in the backend) I seemed to have to use the API to create the user, this was fine, however it doesn’t hash the password with bcrypt that way. So using the front end automatically does that. (I did look at using a bcrypt api, but wasn’t convinced around the security of that).
I think we may have to rethink how we onboard new staff.
Maybe, organisation staff create new staff in front end >> triggers a registration email with link >> new user uses the link to open password reset page >> once password is reset and they re-login, they continue with the onboarding.
Andrew Dam:
Well we do not have to use the API to create the user, as that creates the user in the helper file. The idea is to not create the user in the helper file, but let the authRegister handle the creation of that record.
As long as the user exists in your business file, your onboarding process can be done with a smart link which will finish the registration process and allow them to log-in.
Joe Hardstaff:
Hi Andrew, just for your info. We have solved the password reset. We have hashed the password ourselves using an Api which sends that hashed password to the helper file using the API - CRUD script as part of the process. All tested and satisfies our requirements. This will only be done during onboarding. The usual way will be used for reseting or forgetting passwords once they have completed the onboarding.
Andrew Dam:
Awesome! Glad you were able to solve the issue and found a solution that satisfies your requirements.