Please let me know what you think of this approach. I’m not absolutely sure what Bubble is actually doing behind the scenes, so I can’t be certain this process works the way I think it’s working.
Hokay, so, I’m trying to “hack” Bubble’s system to provide a “passwordless” experience for the user.
The rationale is that password-based security rests almost entirely on the uniqueness and security of the user’s email inbox anyway. It doesn’t matter how many special characters they use if a malicious actor gets into their mailbox and requests a password reset email. Day to day security depends on the token in the user’s browser.
Bubble requires an email+password combo so for pseudo-passwordless I need a password but I’m not going to give it to the user. I’m going to generate a random or temporary password on the fly, store it, and never refer to it again. If the user has to re-authenticate they’ll just get logged out and go back through the “click a link in your email” process.
It starts with the Sign Up popup. The only field that matters is Input Email.
If the user already has an account, and wants to log in again under the same email, we’ve got a problem. Bubble needs the email+password that’s already stored in the database to log the user in. So instead of using the Log User In action we’re going to use the Reset Password action. That’s what the whole system relies on for security anyway.
On the password reset page, we’ll give the user a temporary password and then feed that into Bubble to be stored as their actual password. The user never types in a password or even knows what the new password is.
we’ll also reset the trust_time variable
On the index page, we can set a couple of conditions to log the user out if their email confirmation is “no” or they’ve been logged in too long.