Google Sign-In Conflict with Normal Bubble Sign-In

Seeking thoughts from fellow Bubble developers on a potential issue I encountered when allowing users to Signup/Signin with Google. I have features in my application that allow users to reset a password or change their existing password, as most applications do. The problem I see here is that if a user chooses to Signup with Google, then after that they can only ever Signin with Google, because a normal sign in will never work. Nor will a user be able to reset a password or change a password if they signed in originally with Google. So, does than mean I have to track the method a user used when signing in and block these other options if the user used a Google account to originally sign-up? I see this a potential issue that needs to be addressed so users do not get confused. For example, what if I use my Google account so Sign-up, but then forget I signed up that way and attempt to signin in the future by just entering my Google account or thinking I forgot my password.

Thanks for any thoughts on this!

1 Like

This is a reason I don’t provide sign up with 3rd party sites like Google or Facebook. The issue is not a Bubble issue, but an issue with any site that uses this signup approach and users who forget how they signed up.

One thing to do, which is extra work, and in my opinion, not worth the trouble of allowing sign up with Google (unless you need their profile details from Google) is to setup the alerts to the user that indicate when they attempt to login or sign up again with the same email address used from google account. In those alerts you can provide the user with the suggestion that ‘perhaps you signed up with google account’…so basically, you do not need to track the method of signup (I believe bubble exposes some values if they signup with google - so they basically track it for you) but when a user is trying to login, you don’t know who that user is, until they enter their email address and attempt to login, so the real work comes at that stage to indicate they already have an account and may have used Google to create it, but that also leads to privacy concerns, since somebody else may be using their email address to check if they have an account or not, which is why Bubble changed the language they use to indicate ‘we did not find those credentials’ instead of the old wording of ‘that email address is already in use’.

Again, in my opinion, more of a hassle than it is worth to give the feature, plus most adults should have a password manager these days, making the need to signup with social media accounts obsolete, as for most users, the benefit was not needing to remember multiple passwords.

So, for anyone following this post looking for a “silver bullet” answer to all this, let me just say that @boston85719 is absolutely correct. You really need to consider whether or not its worth it in the end.

Here’s what I learned about the situation. When using a third-party signup option, Bubble creates an 0Auth token and uses that as the identifier for the user, instead of the email address. That user is then forever linked to that account via the token. However, if you collect the available Google user data (email, name, profile image), you can add the email to the account. If a user then performs the “forgot password” option, then can add a password to the account then then log in with either Google or directly with their email and newly created password. Not sure why anyone would actually do this, but it is possible. However, it does not work the other way around. If a user manually creates an account using their gmail address, and then attempts to signup or signin with Google credentials, they will get an error message as @boston85719 explained above.

So, it still becomes messy if a user attempts to mix and match the signin credentials. It is certainly possible to add a flag to the user account when they originally sign up with a third-party, and then present a message to the user when they try to sign in without using the 0Auth client, but is still doesn’t work the other way around, except to trap the 0Auth login failure and add an alert telling them to try signing in the normal way.

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