New users get bounced to index on login — existing users are fine, and the login actually succeeds in the logs
I’ve got a login bug I can’t crack. I create a new user through a back-end provisioning tool and assign them a temporary password — the account saves fine. But when that new user logs in on the live site, they get kicked straight to the index page, and from there the site is broken for them: they can no longer reach the sign-in page or even the public blog, neither of which is behind a login. Opening the site in incognito or after clearing cache fixes everything, so it seems tied to the session state created by the login attempt. The strange part is that existing users sign in with no problem, and if I open the app as the new user via “Run as” from the back end, everything loads correctly — so the user record itself is valid. It only breaks on a real password login by a newly created user.
What I’ve checked and ruled out:
Server Logs confirm “Log the user in” completes successfully for the new user (~35–40 ms, no error) — so the login isn’t being rejected. The bounce to index happens after a successful login.
The redirect to index is client-side — it doesn’t appear in server logs.
The sign-in button’s workflow is just Log the user in → Go to page (gameboard). No conditional branch to index.
Removed every “When page is loaded” workflow on the destination page — no change.
Grouped workflows by event type on the destination page, the main reusable (220+ workflows), the nav reusable, and the sign-in page — every workflow is “an element is clicked.” There are no “Do when condition is true” or “Page is loaded” events that navigate anywhere.
Header script (SEO/metatags) is only scrollbar-hiding CSS; body script is only Google Tag Manager. No JS redirect.
301 redirects are empty.
HTML elements on these pages contain only CSS, no window.location.
Used the app-wide search for both the “Go to page” action and the “Log the user in” action — there’s only one login action (on the sign-in page), and no “Go to page: index” that would explain the bounce.
Tested incognito / cleared cache — public pages load fine with no session; the break is tied to the post-login session.
Odd clue: in Server Logs, the workflow running the login shows as “Button A is clicked,” but there is no element named “Button A” anywhere in my editor (app search returns nothing). After a fresh deploy it showed the expected sign-in button name instead. Not sure if this is relevant.
Has anyone seen a successful “Log the user in” immediately followed by a bounce to index, with no Go-to-page action responsible for it? What am I missing?
I ran this through an AI tool I’ve been building specifically for Bubble debugging — here’s what it came up with, seems worth checking
✦ AI
This pattern — new users logging in, getting bounced to index, and then being locked out of public pages until the session is cleared — almost always points to a privacy rule or page access logic that’s misfiring for users with certain account states. Here’s how this typically happens in Bubble, and what to check next:
Top hypothesis: Privacy rules or conditional redirects are blocking access for users missing a required field or flag
What’s likely happening is:
Your privacy rules (Data tab > Privacy) or a page-level redirect (e.g., in a reusable header or nav) are set up to allow access only if the user meets a certain condition — often something like “Current User’s email confirmed is yes”, “Current User’s onboarding complete is yes”, or “Current User’s [some field] is not empty”.
When you create a user via backend provisioning, that field/flag is left blank or false by default.
On login, the app or a reusable element checks this field and, if it’s not set, redirects the user to index (or blocks access to all pages except index).
Because the session is now “tainted” (the user is logged in but doesn’t meet the required condition), even public pages are blocked until the session is cleared.
How to check/fix:
Go to Data tab > Privacy. Look at the User type. Are there rules that restrict “Find in searches” or “View all fields” to users with a certain field set? Especially check for rules like “When This User’s [field] is yes” or “When Current User is logged in and This User’s [field] is yes”.
Check for onboarding or confirmation logic. In your workflows (especially in header/nav reusables), look for “Go to page” actions that trigger when “Current User’s [field] is not yes” or similar. These are often in “Do when condition is true” or “Page is loaded” events, but can also be in custom events or hidden in reusables.
Compare a provisioned user’s fields to an existing user’s. In the App Data tab, open both users side by side. Is there a field (email confirmed, onboarding complete, etc.) that’s set for the working user but not for the broken one?
Try manually setting that field (e.g., set “email confirmed” to yes, or whatever the difference is) for the new user, then log in again. If the problem disappears, you’ve found the culprit.
If that’s not it, next most likely:
OAuth or password reset state confusion
If your app expects users to have confirmed their email (Settings > Account > “Confirm email” checked), but backend-provisioned users never get/complete the confirmation, Bubble may treat them as “unconfirmed” and restrict access.
Fix: Either uncheck “Confirm email” in Settings > Account, or make sure to set “email confirmed” to yes when provisioning users.
Less likely, but possible:
Corrupted session/cookie or plugin interference
If you have any plugins or custom code that manipulates cookies, sessions, or user state, a mismatch between the backend-provisioned user and what the frontend expects could cause a redirect loop.
Fix: Disable any such plugins or code and test again.
That “Button A” clue:
Bubble sometimes shows “Button A” in logs if the element was renamed or deleted after deployment, or if the workflow was copied from another element. After a fresh deploy, the correct name appears, so this is probably just a stale label in the logs — not the root cause.
Summary:
This is almost certainly a privacy rule or onboarding/confirmation logic that blocks users missing a required field. Check the User privacy rules and
Then you will know what is going on.