Is Password Reset Token stored anywhere?

[thethinklab.au]

Is the password reset token that is created stored anywhere, or do I need to manually create a thing if I want to be able to see it (e.g. creation date etc)???

[davidb]

The token is available within the workflow as the result of your screenshotted action. However, it does not otherwise persist anywhere accessible.

[thethinklab.au]

Thanks @davidb

Yeh I have the flow fully working with SendGrid, there’s just a bug that exists where users sometime trigger 2x resets (clicking the reset button twice). I updated the workflows to change to a confirmation screen after the user clicks a button to requests a pw reset, but there can still be lags etc. I was wondering if there was a way that I could do the following:

• Prevent more than 1 token from being active in the system per user.
• If a user requests an additional reset (either intentionally, or accidentally) while they have an active token, delete/kill the old token and create a new one.

I was wanting to do the following, but this would require a public data type and opens a whole bunch of security issues.

1. When a token is created, store it in the DB along with the email and a status (created time stored by default)
2. When a user requests a new reset with an existing token, update the existing token status to be expired and create a new token.
3. When a user accesses the pw reset link (in email) that includes an expired token, provide a message on the pw reset page that the token is no longer active.
4. When a user successfully completes a pw reset, update the token status.

I’ve seen in the forum that a token lasts for 24 hours, but I can’t find any more info about token default behaviour…

[davidb]

I don’t know. Something to try: Figure out a way to detect on the reset_pw page which token led the user there. If the token isn’t already part of the URL path, maybe include it as a URL parameter in the link you provide. Then, upon page load trigger a backend workflow to compare the page’s token with your inventory of active tokens. If the page’s token is the user’s most recent, then proceed to change the password; otherwise, redirect the user with a message or a literal redirect.

[cyril.legaspi]

Hi @thethinklab.au,

To prevent the reset button from being triggered twice, start by adding a custom state, such as disable, with a yes/no type. Set its initial value to no. Next, configure the button to be unclickable when the disable state is yes. In the workflow, set the custom state disable to yes before executing the reset password action. This ensures the button cannot be clicked again while the process is ongoing.

[thethinklab.au]

Can anyone explain what Bubble’s default behaviour is for password reset tokens when a token is requested for an email that already has an active token?

Does it kill the active token and create a new one, meaning there is only ever one active token in play?

[samnichols]

In general, I like to use a custom yes/no “Clicked?” state for buttons that I use to prevent double clicks. First action in the workflow will be to change the Clicked? state to yes, and last action changes it to no. Button has a condition that makes it unclickable if Clicked? is yes.