Hi!
On my reset password page, I do a search:users using the Reset Token so that I can pre-fill the email and username fields, which I think is pretty neat.
But as the user is not logged in at this moment, it means I need to expose all my users in my privacy data rules to ‘find in searches’… Which is really not ideal…
Would there be a way to send the Reset Token to a backend workflow that would then send back the user, without having to do this in the frontend?
Thank you!
It seems like a long shot, but you can try is to setup an API call through the API Connectir to your own app to retrieve the data.
You would probably need to create a new data type in which you’ll store the Token and the User to retrieve it after.
I’m not sure it will work or be of use in your use case, but I think it’s worth giving it a shot.
In the order :
- Schedule your backend workflow from the frontend
- Find your data and store it somewhere
- Make your API Call to your app to retrieve the data (by using the corresponding token)
I think it should be doable 
Hey @ThomasC2A thanks for your input.
I can kind of see the first 2 steps you suggest but the 3rd is a bit of a mystery… How would you ‘bring the info back’ to the frontend?
I can kind of see how you could alternatively just do it with a new datatype…
- Create a new element with just an email in it
- Expose all those elements
- Search through those elements (low risk)
- Delete element when used
Maybe I’ll try that…
OK thanks @NigelG I’ll try this solution…
I love Nigel’s solution but wanted to throw another solution out there as well. If you just create the token and send a custom password reset email, you can add additional parameters to the link like this. Then simply grab the url parameter to populate your fields.
4 Likes
True 
This is actually quite a nice way to do it. Thanks!
Hi there,
I appreciate this is an old topic, but maybe you guys can help out (?)
Like @tart2000design, my app has a search:users first (inherited from the template I started with), to see if the email exists in the database. It worked fine in the development site, but now in live I have to expose the emails to “Everyone else”, which is not ideal.
My questions are:
- how bad/terrible is exposing the email only on that search? (I assume very bad).
- should I just get rid of the search all together? Not great for UX, but on the other hand, nothing is lost if a bad reset email is sent. Hopefully the user realises the mistake soon enough.
I ask because I consider myself only medium level in Bubble so I can’t really follow up the couple of solutions you discussed.
Thanks!
Why do you need to search for users? The PW reset page/feature should be enough. If the user fails getting in, they should be asked to resubmit their email and then you run the actions again.
Would not recommend exposing all your users.
Well, if the user inputs the wrong email , then the link/token will be useless, and also the user will never get the “reset your password” email, so there’s some logic to search first. You can see the problematic workflow here:
But I’m with you it’s not worth exposing everyone for this functionality.
Thanks for your help @hi.luisacosta . I think I’m going to watch a couple of “back to basic” videos, and I might just rebuild the process from scratch (I think it’s simple enough).
For security reasons, apps now often say “IF we have that email, you will see a reset password email in your inbox”
In other words, if you didn’t get a reset password email
A) you typed it in wrong
B) it’s not your inbox
1 Like