@sridharan.s, ultimately, I think the solution here is to get Bubble to solve whatever it is that represents the “subdomain problem” (by which I take it to mean you don’t have direct access to rules on the web server?).
That being said: Things to think about are the fact that Bubble users can (out of the box) authenticate with either an email/password combination AND/OR via external Oauth 2 credentials. And a user that signs up with Oauth 2 does not have a password – unless you later allow them to create an email/password pair while logged in. (In fact, there’s a read-only system variable for this: User’s uses password (which will only be true if the user uses the email/password login combo… if the User has exclusively Oauth 2 access to your app, this value will resolve to no).
I’ve kind of wondered to myself whether one could implement passwordless and Oauth-less authentication to a Bubble app. (That is, implement the “one-time password” system used in some places where “logging in” involves submitting your email address and then receiving a one-time use password via clicking a link.) It kind of seems like this would be possible, though I’ve not tried hard to implement it.
On the face of it, it seems to me that we are a few pellets shy of a full load on this one. We either need an API to the login system (i.e., be able to build plugins that allow us to trigger the state of being logged in) or an API to the password system (i.e., be able to set the user’s password to some value – not just “reset” the password) to be able to do this.
But I do wonder if perhaps one could create an external API (or even do it via the POST API workflow of one’s app) that impersonates an Oauth 2 API and, thereby, provides credentials that are NOT Oauth 2 but are in fact some other secure-ish system.
Anyway, there’s nothing inherently “connected” about user authentication and custom subdomains. And it seems to me that – rather than hacking about which will surely lead to security issues – one should just design and press for the solution that one needs with the engineering team at Bubble.
Now, of course, Bubble may not be able to accommodate such solutions on the shared clusters. But it would seem eminently doable on a dedicated cluster.
AND, all of that being said, I’d be very interested to understand how in-browser authentication works in Bubble as I don’t quite grok how it works. (And the reason that I don’t is that we don’t have a programmable API to those features.)
This is the sort of thing we’d need a Bubble person to chime in on, really.
And while this subject is of academic interest to me there are many more features that I’d rather have (e.g., a GET method for API workflows – which, seriously, is an afternoon of work to fix) than some interface to the password system and/or support for user subdomains (but also that doesn’t seem like much work to add, either).
I kinda had the impression that the app you’re talking about was on a dedicated system, anyway. Isn’t this request a professional services engagement type thing for you rather than a hail-mary pass for assistance from the peanut gallery? 