Creating user without an email

Tips
1

Probably said before but since a friend needed help, I figured I would post this here:

How to set up users in Bubble without requiring their actual email addresses, by creating a fake email entry:

  1. Unique Identifier:

Start by choosing a unique identifier for each user. This could be something like their phone number, username, or any other unique data specific to the user. The uniqueness of this identifier is crucial because it will serve as the base for creating a fake email address

  1. Creating a Fake Email Address:

Use the unique identifier as the first part of the email. For example, if you’re using a phone number, the email might start as 1234567890@.
Append this identifier with a fake domain. This domain doesn’t need to be a real, active domain. It’s just a placeholder to satisfy the email format requirement in Bubble. For instance, @user.com. So, the full fake email for the phone number example would be `[email protected]’

  1. Custom Usernames:

If each user creates a custom username, you can use this as part of the fake email. For example, a username like ‘Sammich’ would become part of the email: [email protected].
To enhance uniqueness, append a random string or number to the username before the domain. For example, [email protected].

  1. Logging In:

When a user tries to log in, you’ll use the “log the user in” function in Bubble.
You’ll take the username or identifier they provide and programmatically append the preset fake email ending. For example, if a user logs in with the username ‘Sammich’, the system will automatically complete their email as [email protected] (assuming ‘1234567’ is the random string you’ve appended).

  1. Why This Works:

Bubble requires an email for user registration and login, but it doesn’t need to be a real email address. By using this method, you can create a user account without needing the user’s actual email.
This approach allows you to manage user accounts internally while keeping the user experience simple and straightforward.

NOTE!
It’s important to make sure that whatever method you use for generating these fake emails consistently produces unique addresses for each user. Also, be aware that since these are not real email addresses, you won’t be able to use them for email communications or email-based password recovery.

2 Likes
2

Hi,

With this approach, let’s assume there is OTP for validation.
During signup a password is assigned to the user and is stored somewhere in the table, When the user logs in we need to check db for matching email and use the stored password to log the user in.
So we have to search for the password before the users are logged in, for this to be possible privacy rules needs to be disabled for the password field.

Doesn’t this leak the user info? Please correct me if I am wrong.

Thanks,
Ram.

3

I am assuming @hi.luisacosta’s friend is using phone numbers for login, and you can send a magic link by sms/whatsapp without ever needing a password. If you generate a “temporary” pw it’s never exposed and you never need it again using this method.

I can just add that you should maybe not use a random domain, as it might exist, or might start existing and that might be a security vulnerability you don’t want. As a workaround, you can use the “+” symbol in your own email, and then follow that by the unique identifier, like [email protected].

2 Likes
4

What kind of security vulnerability do you have in mind? I can’t think of a scenario where it could be an issue? Similarly, I can’t see why it makes any difference if the domain exists.

Nevertheless, the best practice likely would be to use the site’s domain, as in case you mess up, you catch it, and it’s helpful for white-labeling your app on different domains by letting you save a field on the ever-precious user table.

1 Like
5

Bubble sends pw reset info to the account email on file if it exists in their db. If I’m getting the email to the domain I just bought I can sign in. That’s just the easy one :wink:

6

If you set it up that way, you should never have any emails sent from Bubble, even if you’re ready to live on the edge and utilize Bubble’s native email.

Who are you in that case? The app owner - so what’s the problem? a End user, they can’t buy a owned domain and again even if they do no emails are going out.

If you are using usernames and send out any email thru Bubble then yeah you got major problems but assuming you spend 5 minutes making sure that can’t happen there are no security issues.

7

To clarify, I mean this one, where you send the user a password reset email. I assume quite a few people use it still. If you can see or guess the spoofed email, you can log in as the user.

image

I’m not saying it will be a big issue for expert developpers such as yourself, it was more a “close this attack vector because why not?” comment. If you’d like to continue this discussion I’m happy to take it offline. Dm me.

1 Like
8

Hi all good replies.

About the domain; yeah please use your own domain OR a very random string that has a low chance of anyone every buying it if you really must. Using an existing domain could in theory cause issues where that domain owner can access the user accounts and reset PW. Just avoid that lol.

With this method, you lose all email access until the user provides an email (if ever). So you should not be sending them a OTP or Reset PW email through there. You can create a Reset PW token and navigate them to the page without sending an email. You’ll have to set up some user verification method I guess.

9

I know what you meant. As I said, you prob shouldn’t use that action ever and certainly not for a non email app. And that’s why if the app domain is the email it will only go to the app domain which is owned by… the app admin.

Not sure where the guessing comes in as that only applies to the email address but still won’t help one login?