Bubble keeps trying to login the temporary user it created in my browser


I’m having a weird problem. The sign-up process on my app uses the ‘create an account for someone else’ workflow. This all works well, up till the point I try to log in for the first time using the temporary password.

At this point, the log-in workflow just doesn’t run:
I have conditions on the log-in button to redirect users based on their user type (The user type is set when the user initially signs up -I’ve checked the database, and my test users all have the right user-types attached to their records).

But when I check the debugger, it shows that the conditions fail, and so the workflow doesn’t run. The reason the condition fails, is because the workflow is trying to evaluate the current user - but for some reason, this current user isn’t the user email input in the log in screen!
Instead, the debugger shows me a current user that was created a few minutes ago, no name, no user type, and a unique ID that doesn’t exist in my database. And so I imagine this is Bubble creating a ‘temporary user’.

What I don’t understand is why is Bubble trying to log in the temporary user, rather than evaluating the user attached to the email in the log-in workflow?

Does anyone know what I should be doing instead? Would appreciate any tips.


If a user is signing in with a temporary password, Bubble will automatically redirect them to the password reset page so that they can set their own permanent password; this is likely what’s overriding the conditions you’re trying to set. :slight_smile:

Hey… thanks for the response.

I figured out what the issue was, and so posting here, in case it something similar happens to anyone:

I had conditions set on the Log In button, and had multiple Log In button actions in my workflow:

  1. When Login button is clicked and only when user’s user type is Type A - log user in, then go to page A

  2. When Login button is clicked and only when user’s user type is Type B - Log user in, then go to page B

Etc, etc.

It seems Bubble was unable to evaluate the user’s type, because the user was YET to be logged in at the time it was being asked to do that evaluation. I don’t know if it has always been like this, and maybe this is the intended behaviour

(I thought it would be able to sort of run the user’s email and figure out the user’s type, as they are being logged in)

The solution was to use just a single Log In Action. Then to log the user in in Step 1, and then subsequent steps carry out the “only when” evaluations: Step 2 - go to page A, only when user type is type A. Step 3 - go to page B, only when user type is type B. etc etc etc

The automatic redirect from Bubble’s end, to the password change page for temporary password-holders, still happened as expected, when necessary.


This topic was automatically closed after 70 days. New replies are no longer allowed.