Single page app: How to use social (LinkedIn) login WITHOUT reloading page (thus losing data)?

I’ve got a B2B app and really want to use LinkedIn authentication rather than native login. It works fine in general, but my problem is that the app does not prompt the user to create an account until they’ve already received some value. This is good UX (vs. requiring sign-in before they can do anything), but it’s a problem because when the user clicks the ‘Sign in with LinkedIn button’ and goes through the OAuth flow, the page reloads and they lose their place + data.

Is there any way to authenticate in a popup or new tab so that the user does not lose her place in the single-page application, and associated data? If so, I’m struggling to find it.



There must be a better way, but for anyone else dealing with this, here’s a workaround.

  1. Set up a new blank page in your app; I created one called auth.
  2. Create a workflow event on your social login button click to Go to your blank page (e.g., auth), sending along one or more url parameters that you need to “save” while the OAuth flow is executing.
  3. On load of your blank page, trigger another workflow event, with condition “Only when user is not logged in” (to your app) (<<< important to avoid endless loop), to sign up with your social network.
  4. The social network’s OAuth flow will then be executed; if user is already logged into their social network and has authenticated your app before, you’ll just see a page blip. If not already logged in to their social network and/or has not previously authenticated your app, then they will be presented with the expected screen.
  5. When the OAuth cycle is complete, it redirects to the /auth page (as you would specify in your app’s settings of whatever social provider, in my case my LinkedIn app). On this redirect page (still auth), trigger a workflow event “When user is logged in” to simply “Go to” your main app page, again sending the needed url parameters back.
  6. Set the data source of whatever data-driven sections you need using Bubble’s “Get data from page URL” function to pull the parameters back in.

Using this flow, I was able to keep users in their primary flow of the single-page application despite inserting a a social OAuth redirect right in the middle of it.

It’s still not ideal because the page/content flickers a bit, but it works.


Has any solved this? Stuck on the same issue

Drop a cookie or use local storage. Example of cookies for exactly this explained here How to attach anonymous data to existing user after they log in?

Could you not just use auto bind and save the values to the current user?

Depends on the specific use case.

If the use case is that we’re in some preview flow and expecting (hoping) the visitor converts to a “real” user by signing up/logging in sometime during the flow, yeah, you could do this.

But if the case is that we allow visitors (who may be correspond to either completely new or previously-registered Users) to just show up and do stuff and, then, at some point require them to log in to complete their action, NO we cannot do this.

Because we cannot assume that Bubble correctly identifies the User with an account.

There’s always a Current User. Let’s say I’m a registered User of your site. But now I’m logged out and I go visit your site from an incognito window. I will be assigned a User ID (via a cookie) – the session is unauthenticated (I’m not logged in) but I’m a User – I’m some temporary User with a unique_id that has been assigned.

(This is easy to demonstrate, BTW, just create a page in any Bubble app, that has a text element on it that says, "Welcome, Current User's :unique_id!") and visit it incognito. Now visit it from another incognito window. See how your unique_ids aren’t the same?)

The problem is this: If I now do some stuff on the page and log in via social, two things happen:

  1. I become the “correct” User and assume that identity. Anything you saved on the temporary fake User is now gone.

  2. I lose the state of the page because it reloads.

So, to work around that, we have to store important state info for the page locally before allowing the user to log in with social and then read that local info back in to establish page state after the social login is complete and our page has reloaded.

Of course, it’s much easier to just not allow unauthenticated to do anything meaningful and require a login. But this isn’t always desirable.

The rule of thumb that I suggest, however, is that OF COURSE you shouldn’t allow unauthenticated visitors to do stuff that creates objects in your database (because of course any user agent, not just a real human visitor, could potentially interact with your page). Any sort of things you allow should of course happen only in the page and be easily representable via cookies – or, if more data storage is necessary via values stored in local storage.

The broader problem here BTW (in the context of the now very old original post) is that “Single Page App” isn’t just a presentation-layer approach (or a stylistic preference), it’s an architecture. And it’s an architecture that Bubble doesn’t support very well in it’s current form.

There’s no reason it couldn’t be more friendly to single-page app creation, but it would take some changes. Some of these are quite minor. For example, giving programmers some access to what happens in the case of undefined URLs (routing rules). Because Bubble is designed in a specific way, inbound URLs are assumed to refer to some pre-defined page in the app. The classic example is this:

In Bubble this means, “open the page in named ‘keith’.”

But lots of people want this to mean, “See that path? Check and see if there’s a User object with username ‘keith’. If so, display the User profile page for User with username ‘keith’.”

In the first case, if there isn’t a real page named ‘keith’ that we can serve up, we redirect to the 404 page. As a result, we always go 404 in the second case.

In a Single Page App, we desire a facility that’s like the second case. We’d like to put some code at the server level that would let us disambiguate URLs and do something sensible, BEFORE going 404. (Basically, “real” single page apps – by which I mean SPAs built in a framework like React or similar – really only have one endpoint and that endpoint figures out what to do with arbitrary paths and querystrings that come into that endpoint. In Bubble, we have multiple endpoints, but less flexibility in terms of what happens there… and no facility for handling arbitrary endpoint URLs.)

It would be rad if we could set a preference in our Bubble app such that, before going 404, we execute some code to disambiguate the unknown URL and route to known pages. This would make doing /keith as a user profile page trivial and let us do fancy things like send state information to the main endpoint of an SPA page.

This would be a fairly easy feature for Bubble to add, as long as the feature were code based. And therein lies the rub, right?

But Bubble’s not about that. Bubble’s (at some level) about enabling non-web-developers to build things that are kinda-sorta on par with things built by people who understand web development.

So I wouldn’t expect a quick resolution to this issue. (Though, who knows, perhaps Bubble is thinking about this and working on this. It would be a natural thing to do.)

But anyway, back to the broader topic at hand, what Single Page Apps do is manage their internal state locally and are very good at re-establishing their state after something like a page reload.

So it shouldn’t surprise anyone building a “single page app” in Bubble that – duh – they’re going to need to at times save the state and re-establish it. But of course, the people building “single page apps” in Bubble often don’t actually know what it is they are doing and so are surprised when they learn the requirements of what it is they are attempting to do. :man_shrugging:

All the above being said: It wouldn’t be that hard to retool Bubble to be more React-like (it’s already remarkable React-like, really), but it poses a completely new set of challenges in terms of how you build the point-and-click interfaces to support no-code development of this type.

But in terms of arbitrary URL processing we actually already have almost everything we need: We have SSAs (which run nodejs code on the server and can return arbitrary text [and other data type] results). All we need is a way to insert an SSA between Bubble’s default routing strategy and the issuance of a 404, and a mechanism (API) for telling Bubble, "Hey, don’t return 404 and go to the 404 page, go here instead.) And… problem solved. (Concerns about spin-up time of SSAs, notwithstanding.)

was struggling with this for some time after working on updating my buddy’s loan agent website and we arrived at the need for loan agents to have secure document delivery, but I wasn’t happy with and wanted something simpler, like or even

so the light bulb went off that I could just use my reusable element from the index page and load the 404 with that. now i can just have a clean url and no one’s the wiser. maybe this will suck for seo, but i’ve kinda given up on seo and am going the “word of mouth” route…

the final step is working on a plugin to easily append the url path. i can read the url easily enough thanks to the regX testing site regex101: build, test, and debug regex

now i just want to make it so that i can easily write to the url. this will let me save the page state (in case the user hits the refresh button) and i should be good to go!

(sometimes i wonder if worrying about page state is an edge case, but i can’t “fight the feeling”… also, i think it’s nifty for the user to be able to bookmark the page and come back right where they left off…)

Hi @varshneyandson,

Unfortunately, that’s not a recommended practice. By definition, a 404 means the resource can’t be found.

Except for every search engine on the planet.

It’s one thing not to care about SEO, but quite another to actively work to ensure the content isn’t found by search engines.

A single Bubble page - even one with a single-character name - could be used to avoid the 404; but if you truly don’t care if the content at that URL is as “discoverable” as it could be, then maybe it’s not such a big deal. I would never use that approach or recommend it for a business app though.



it will be interesting to see what happens over time because the 404 is just a clone of the index page. so all the content will be available via the index page as well. will keep you guys posted