The UX issue we have is that when a password reset token has expired, Bubble does not create a notification message that the token is expired but creates a message that the password in invalid.
A user that for example gets an invite from a colleague on a Friday and starts working with the app on Monday starts by “hating” our application. They follow the password complexity instructions but each time get a message that the password is invalid… so they try it again..and again.. and again.. and ultimately give up and call us. That is when we explain the token expired after 24 and they need to trigger a new password reset.. after that it is a walk in the park..
The issue is that the alert message says the Password is invalid but in fact the token is expired. This is very confusing (and frustrating) from a UX perspective!!!
Questions
A. Can Bubble change the error message into something like “Your token has expired” when that is the issue? B. Since the above will likely take a long time to get noticed and/or implemented. Is there a simple workflow or trick that can check the token vallidaty without trigerring it and rendering it invalid - preferably client side?
Ok couldn’t resist without thinking things through..
Added token and token stamp field to the User.
Set a do when condition is true on the password reset page
(i.e. when Current date/time - 1 Days > Search for user (token = get “reset” from page url) first item’s time.stamp) and then setting an expired visible thing and the standard pw reset on that condition being fulfileld via a state.
Testing works fine but only because i’m logged in. When I’m not logged in.. indeed you guessed.. privacy rules prevent the effective do a search for on the token.
I think it would be bad practice to set the token type to an anyone can view is true.
A hypothetical workaround would be to perform a validation in the backend however that would still require an ignore privacy rules in the workflow.
Got it.. actually more simple than i thought.. add the timestamp to parameter for page trigger..simple and elegant
works like a charm..
Extended the password reset e-mail link with a simple parameter: &exp=current date/time in ISO and set a condition on the page that checks if the this token is older than 24 hours ago (current dat/time - 1 days). If that is the case the user will not get to see the password reset.
our application. They follow the password complexity instructions but each time get a message that the password is invalid… so they try it again..and again.. and again.. and ultimately give up and call us. That is when we explain the token expired after 24 and they need to trigger a new password reset.. after that it is a walk in the park..
