User accounts
This article covers how you create and manage Users in your app
Last updated
This article covers how you create and manage Users in your app
Last updated
In this article, we're going to explore how Bubble's handles the process of setting up and managing user accounts.
Technically, users are just another data type stored in your app's database, but there are several reasons why Bubble treats the user type a bit differently:
The built-in user authentication system provides robust security features to safeguard user data, such as password hashing, salting and encryption
Processes like signing up, logging in and remembering a user between sessions are automated
Features such as confirming email addresses, securely resetting passwords, 2-factor authentication, magic login links and generating/assigning temporary passwords are all securely handled
Bubble sets up temporary users whenever non-logged in users visit your site. Data stored on that user is automatically transferred when the user completes their sign-up (this is useful to store a a new users shopping cart for example)
Privacy Rules treat users differently than other data types, allowing you to control access to data based on fields stored on each individual user. This lets you manage user permissions and control access to sensitive data in a granular way
In short, managing user accounts demands strict security to ensure the protection of users' sensitive information, and the functionality of user accounts remains fairly uniform across different platforms. This is why Bubble takes care of this aspect of your application's development, saving you development time while ensuring that your app is up-to-date with the latest security standards.
Most of us have dozens or even hundreds of user accounts in our lives: we're logged into our phones, our email accounts, social media, forums and even newspapers. Of course, we all know what they are, so let's change perspective a bit: why does an app need user accounts?
The first answer to that question is that not all apps do: it's perfectly possible to create a highly useful app where the user never creates an account at all, even if you allow users to add and change things in the database. So let's first note that down: your app can have, users or registered users or both. This article focuses on registered users – that is, users that have signed up with their email and a password or a through a .
Registering users serves many purposes:
Keeping data private: in many contexts a user should only have access to the data they themselves own or that of a select group of other users
Saving settings: many apps allow users to save preferences and profile details that are still there the next time they use the app
Controlling Access: many apps allow only registered users to access its pages
Assigning roles and permissions: having registered users allows you to identify each one and assign them roles that control what they have permission to access
Personalization: some applications, such as social media and eCommerce stores, offer a stream of personalized content for each user
Teaming up: some apps will need to team people together so that they can share data and collaborate. To control who has access to what you'll need to know who they are
Payment processing: to process payments and maintain an order and payment history you will usually want to attach it to a permanent user
Communication: by knowing who your users are, you can communicate with them through the app or external channels like email
As you can see, there are many reasons for why you would want a user to sign up, and it's not only related to security and privacy. Just like any other data type, you can add as many different fields as you need, but the user type also comes with a few extra fields to handle the account.
These fields can't be changed or deleted and are the same across all Bubble applications.
In addition to the four on all data types, the user also comes with three additional fields:
Password (invisible)
Email confirmed (invisible)
These fields have the following properties:
The email field can never be empty on a registered user and needs to be formatted as a valid email address. Every user in your app needs to have a unique email address.
The password field is different from all other fields in that it is invisible even to you as the app developer. The password is kept secure in accordance with industry-standard practices.
The email confirmed is another invisible field. It holds a yes/no value that reflects whether the relevant user has confirmed their email using the Send confirmation email action. You cannot make changes to this field directly – the user must perform the action described above to update it.
This article explores common related to user accounts, but doesn't provide details on every available user action. To learn more about what actions and are available on users, you can check out the resources below: Reference: List of user account actions Reference: List of user operators
While the technical process of signing up is handled by Bubble, the design and user experience is entirely up to you.
When you want to sign a user up, you need that user to provide two strings of text: a valid email address that's unique in your app and a password.
The email and password will usually be provided through input elements. In the example above we have two input elements where the new user types in their password: one to set the password and the second to confirm that they didn't misspell it.
Users in your app must have a unique email address.
The information is sent to Bubble's server in an encrypted state, and the password is hashed and salted – a that means that no one can read it – not even the Bubble team.
Keep in mind that input elements can be set up to format their input in a certain way (such as replacing the characters in a password input field with asterisks) and to expect a certain format (such as a valid email address). We recommend using both of these features when setting up both signup and login forms. Article section: Input elements
As soon as this action has been triggered the account will be created and the user is logged in from that point on. A logged-in session lasts for 12 months or until the user logs out or deletes the cookies from their browser.
The log in action is very similar to the sign up action in that it requires two pieces of input: the email and the password. Bubble then sends this data in an encrypted state to the server to check the credentials. If they are both correct the user is logged in.
An SSA provider is a third-party service that you can use to let users log in. For example,
The most common way to authenticate users is to prompt them to enter a password or an email. However, sometimes, you will be using some external such as Facebook, LinkedIn or Gmail to authenticate users using their credentials from that service.
This has a few advantages to consider:
It lets users authenticate faster, and they don't need to remember another password. The signup process is usually done with a few quick clicks (depending on the external service and whether the user is already logged in)
This will sometimes let you fetch some data on behalf of the users, such as their email, profile pictures and social media posts
We'll use Facebook as an example below (in other words, your app offers a button 'Login with Facebook'.).
The guide below describes how Facebook login works overall. To read more about the different settings on the Facebook login plugin, check out the resources below. Reference: Facebook
When you set up such a flow in Bubble, you will need to define the level of you want from your users for your app to function. By default, most services only expose the public profile and the email when users sign up on a third party application using their credentials, but you can ask for more permissions (for instance, post on their wall).
It's best practice both from a user and security perspective to only ask for permissions if you need them, and it's worth keeping in mind that asking for a long list of permissions can lead to fewer users signing up.
When a user signs up with a social network (Facebook) in Bubble, a new user is created in the database, similarly to a traditional sign up flow with email and password.
The main difference is that the way to login for the user, once logged out, will not be by entering their password (since they didn't define one), but by logging in with Facebook. If a user is logged in with Facebook and your app uses Facebook login in the same browser, the user is automatically logged in as that Facebook user.
Users in Bubble can use traditional logins and social logins at the same time. There are a few cases here.
If the user is currently logged in with email and password, you can prompt them to link their account with an Oauth provider (such as Facebook, Google ...). If a user goes through such a flow, a new user will not be created, but, instead, the auth credentials will be added to the current, logged-in user. After this flow completes, the user will be able to login either with his email/password, or via an Oath flow. If another user exists in the database with the email provided by the external service, the action will fail and a message will be shown to the user.
If the user isn't logged in when he goes through an Oath flow, a new user will be created, except if a user with the same email (the email registered with Facebook) already exists in the app's database. In such a case, the workflow will fail and a message will be shown to the user.
If a user has signed up with an external service and wishes to add a password to his account, he can do this by going through a 'reset the user's password' action. This will effectively modify the user that was authenticating only with Oath credentials and will the email and password values to the user object.
The moment you sign a user up is when you assign them an email address and permanent storage in the database. In many cases (but not always) this is also when a user provides a password to use to access the account later.
From a data perspective, Bubble actually keeps track of who the user is at an earlier point (with one ): whenever a new user visits your application, Bubble saves a cookie in their browser and creates a temporary user.
This Bubble feature means that as long as your app allows for cookies, the current user data source will never return an empty value. If you want to check whether a user is actually signed in, you can use the current user operator.
This allows you to "remember" who the user is during the session, and lets you set up application logic that rely on accessing data stored on the current user.
This is useful in different scenarios:
Saving preferences and settings
Storing temporary data like a shopping cart
Personalizing the user experience
When the sign-up process is completed, Bubble transfers the temporary data over to the newly created user automatically.
Data stored on a temporary user is transferred automatically when the user signs up, but not when they log in.
It's widely regarded as a basic security best practice that no one, not even the developer of an app, should have access to a user's password. The best way to help a user log in if they have lost their password is to help them reset the password or to generate a temporary one.
Yes, you can use the Log out other user's sessions action for that. Note that this action logs the user out from all devices except the one they are running the action from. If you want that session to log out as well you'll need to use the Log the user out action.
It depends on the settings you set in the Log the user in action:
Temporary users (those who haven't signed up but have a cookie) will remain active on the same device for 72 hours
If the Keep the user logged in checkbox is unchecked, the user will be logged out after 24 hours
If the box is checked, the user will be logged out after 12 months
There are other instances where the user will be logged out:
If the Log the user out action is triggered
If the Log out other user's sessions is triggered on another device
If the user clears their browser's cookies
No, there's no difference between the two: they will both let you change any custom field on the user.
The password field is special in that it's considered a part of the user's credentials. That's why we have a dedicated action for updating it called Update the user's credentials. For security reasons, this action requires that the user re-enter their password (meaning that you need to set up an input element for it).
