Bubble Docs
  • Introduction
  • New? Start Here
  • What is Bubble?
  • The Glossary
  • User manual
    • Getting started
      • What is Bubble?
      • Building your first app
        • Planning features
        • Database structure
        • Design and UX
        • eCommerce and payments
          • Shopping cart
          • Checkout page
          • One-time payments
          • Subscriptions
          • Marketplace
      • Creating and managing apps
      • The Bubble editor
        • Tabs and sections
          • Design tab
            • The element tree
            • The property editor
          • Workflow tab
          • Data tab
          • Styles tab
          • Plugins tab
          • Settings tab
            • Application settings
              • Custom headers/body
              • Visual settings
              • Social media sharing
              • Translating your app
              • Email settings
              • Collaboration
            • Custom domain and DNS
          • Logs tab
        • Tools
          • Key features
          • The search tool
          • The Issue Checker
          • The element tree
          • The element property editor
          • The debugger
          • Notes
        • Previewing your app
      • Transitioning to Bubble from...
        • JavaScript
        • HTML and CSS
        • SQL
    • Design
      • Elements
        • The element hierarchy
          • The element tree
        • The page
        • Containers
          • Groups
          • Repeating groups
          • Table elements
          • Popups
          • Floating groups
          • Group focus
        • Visual elements
        • Input forms
          • Text and numbers
          • Dates and time
          • File uploads
          • Selection controls
        • Reusable Elements
      • Styling
        • Color variables
        • Font variables
        • Styles
        • Custom Fonts
      • Responsive design
        • Building responsive pages
        • Legacy articles
          • The Basics (Legacy)
          • Building Responsive Pages (Legacy)
          • Migrating Legacy Pages
          • Tips When Designing (Legacy)
      • Templates
      • The Component Library
      • Importing from Figma
    • Data
      • The database
        • Data types and fields
        • Creating, saving and deleting data
        • Finding data
        • Displaying data
        • Protecting data with privacy rules
        • The database editor
        • Export/import data
          • Exporting data
          • Importing data (CSV)
        • Working with location data
        • Using Algolia
        • Database structure by app type
          • Marketplace Apps
          • Directory & Listings Apps
          • Social Network Apps
          • SaaS Apps
          • Project Management Apps
          • CRM Apps
          • Professional Services Apps
          • On-demand Apps
          • Documentation/ CMS Apps
          • Applicant Tracking System (ATS) Apps
          • Portfolio Apps
          • Gallery Apps
          • Online Store / Ecommerce Apps
          • Blog Apps
          • Messaging App
          • Dashboards
          • Building Block Apps
          • Bubble as a backend
      • Files
      • Images
      • Static data
        • App texts (translations)
        • Option sets
      • Temporary data
        • Custom states
        • URL parameters
      • User accounts
        • Authentication plugins
          • Facebook plugin
          • Fitbit plugin
          • Google plugin
          • Instagram plugin
          • LinkedIn plugin
          • Pinterest plugin
          • Slack plugin
          • Wistia plugin
          • YouTube plugin
        • Cookies set by Bubble
      • Time, dates and time zones
    • Logic
      • The frontend and backend
      • Workflows
        • Events
          • Frontend events
            • Recurring workflows
            • Custom events
          • Backend events
            • Database trigger events
        • Actions
        • API Workflows
      • Dynamic expressions
      • Conditions
      • Navigation
        • Single-page applications (SPA)
        • Multi-page applications
        • Page slugs
    • Workload
      • Understanding workload
        • Activity types
        • The workload calculation
        • Client-side and server-side processing
      • Tracking workload
        • Measuring
          • Using App Metrics
        • Monitoring
          • Workload notifications
          • Infinite recursion protection
      • Optimizing workload
        • Optimization framework
        • Optimization checklist
          • Page load
          • Searches
          • Workflows and actions
          • Backend workflows
        • Agency showcases
          • Minimum Studio
          • Neam
          • Support Dept
    • Security
      • Bubble's security features
      • Planning app security
      • Client-side and server-side
      • Bubble account security
      • App security
      • Page security
      • Database security
      • API security
        • API Connector security
        • Data API security
        • Workflow API security
      • Flusk
        • Overview
        • Flusk plan features
        • Getting started with Flusk
        • Flusk security tools
          • The Issues Explorer
          • Issue details
          • Tools and settings
            • Pages rating
            • Database rating
        • Flusk FAQ
      • Cookies
      • Security checklist
    • Publishing your app
      • Web app
      • Native mobile app
        • Global native mobile settings
        • iOS App Store
        • Google Play Store
        • Publishing FAQ
    • AI
      • Generate apps with AI
        • About AI app generation
      • AI page designer
      • Connect to AI agents
    • Maintenance
      • Collaborators
      • Version control
        • Best practices: Version control
        • Transitioning from the legacy version control
        • Terminology: Version control
        • Version Control (legacy)
      • Commenting
      • Database maintenance
        • Copying the database
        • Restoring database backups
        • Bulk operations
          • Bulk operation methods compared
        • Wiping change history
      • Performance
        • Hard limits
        • Capacity Usage (legacy)
        • Notes on queries
      • SEO
        • Introduction to SEO
        • SEO: App
        • SEO: Page
      • Testing and debugging
        • Introduction to testing and debugging
        • The debugger
        • The server logs
        • Supported browsers
      • API workflow scheduler
    • Integrations
      • API
        • Introduction to APIs
          • What is a RESTful API?
        • The Bubble API
          • Bubble API terminology
          • Authentication
            • How to authenticate
            • No authentication
            • As a User
            • As an admin
          • The Data API
            • Data API Privacy Rules
            • Data API endpoints
            • Data API requests
          • The Workflow API
            • Workflow API privacy rules
            • Workflow API endpoints
            • API workflows
              • Creating API workflows
              • Scheduling API workflows
              • Recursive API workflows
              • API Workflow Scheduler
              • Case: Stripe notifications
        • The API Connector
          • Authentication
          • API Connector security
          • API guides
            • OpenAI
              • Authentication
              • Calls
                • ChatGPT
                  • Chat
            • Google Translate
              • How to setup Google API keys
          • Streaming API
        • API security
        • Plugins that connect to APIs
        • API Glossary
      • Plugins
        • What Plugins Can Do
        • Installing and using Plugins
        • Authentication plugins
        • Special Plugins
      • SQL Database Connector
      • Bubble App Connector
      • WorkOS
        • WorkOS SSO
        • WorkOS API
    • Infrastructure
      • Sub-apps
      • Bubble release tiers
      • Hosting and scaling
        • How Bubble hosting works
        • Scaling with Bubble
        • CDN (Cloudflare)
        • Bubble app names
        • Domain and DNS
      • Compliance
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks and standards
    • Bubble for Enterprise
      • Hosting and infrastructure
        • Dedicated instance
          • The Dedicated editor experience
          • Technical specs
          • Main cluster dependencies
          • Customizable options
          • Migration process
            • Pre-migration
            • During migration
            • Post-migration
      • Security and compliance
        • Single sign-on (SSO)
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks
        • Bubble's security features
      • Admin and collaboration
      • Priority support
      • Billing and Payment Guideline for Dedicated Instances
  • Core Reference
    • Using the core reference
    • Bubble's Interface
      • Design tab
      • Design tab (Legacy)
      • Workflow tab
      • Data tab
      • Styles tab
      • Styles tab (Legacy)
      • Plugins tab
      • Settings tab
      • Logs tab
      • Template tab
      • Toolbar
      • Top and context menu options
      • Deployment and version control
        • Deployment & Version Control Dropdown (legacy)
      • Notes
    • Elements
      • General properties
      • General properties (Legacy)
      • Styling properties
      • Styling Properties (Legacy)
      • Responsive Properties
      • Responsive Properties (Legacy)
      • Conditional formatting
      • States
      • Page Element
        • Page Element (Legacy)
      • Visual Elements
      • Containers
      • Container Layout Types
      • Containers (Legacy)
      • Input Forms
      • Reusable Elements
      • Element Templates (legacy)
    • Workflows
    • Events
      • General events
      • Element events
      • Custom events
      • Recurring event
      • Database trigger event
    • Actions
      • Account
      • Navigation
      • Data (things)
      • Email
      • Element
      • Custom
    • Data
      • Data Sources
      • Operators and comparisons
      • Search
      • Privacy
    • Styles
    • API
      • The Bubble API
        • The Data API
          • Authentication
          • Data API endpoints
          • Data API requests
        • The Workflow API
      • The API Connector
        • Authentication
        • Adding calls
    • Bubble-made Plugins
      • AddtoAny Share Buttons
      • Airtable
      • API Connector
      • Blockspring
      • Box
      • Braintree
      • Bubble App Connector
      • Chart.js
      • Circle Music Player
      • Draggable Elements
      • Dropzone
      • Facebook
      • Fitbit
      • Full Calendar
      • Google
      • Google Analytics
      • Google Optimize
      • Google Places
      • Ionic Elements
      • iTunes
      • Slidebar Menu
      • LinkedIn
      • Localize Translation
      • Mixpanel
      • Mouse & Keyboard Interactions
      • Multiselect Dropdown
      • Progress Bar
      • Rich Text Editor
      • Rich Text Editor (Legacy)
      • Screenshotlayer
      • SelectPDF
      • Slack
      • Segment
      • Slick Slideshow
      • SQL Database Connector
      • Star Rating
      • Stripe
      • Tinder-like Element
      • Twitter
      • YouTube
      • Zapier
    • Application Settings
      • App plan
      • General
      • Domain / email
      • Languages
      • SEO / metatags
      • API
      • Collaboration
      • Sub-apps
      • Versions
  • Account & Marketplace
    • Account and billing
      • Pricing and plans
        • Plans and billing
        • Billing cycle
        • FAQ: Pricing and Workload
      • Account Management
      • Building Apps for Others
      • Selling on the Marketplace
      • Plans & Billing (legacy)
    • Official Bubble Certification
      • Hiring certified developers
    • Building Plugins
      • The Plugin Editor
      • General Settings
      • Updating to Plugin API v4
      • Adding API Connections
      • Building Elements
      • Building Actions
      • Loading Data
      • Publishing and versioning
      • Github Integration
    • Building Templates
    • Application and data ownership
    • Marketplace policies
    • Bug reports
  • Vulnerability Disclosure Policy
  • Beta features
    • About the Beta features section
    • Native mobile apps 🔒
      • Introduction
        • What is a native mobile app?
        • Native mobile vs. web development
        • Differences in native and web elements
        • Native mobile app terminology
      • Building
        • Views and navigation
        • Native mobile actions
        • Components and gestures
        • Device resources
          • Location services
          • Camera/photo library
      • Previewing
      • Publishing
Powered by GitBook
On this page
  • What is a user account?
  • Built-in fields
  • User actions
  • Signing up
  • Logging in
  • Signing up and logging in with an SSO provider
  • OAuth - signing up and logging in with a third-party service
  • Signing up with Facebook
  • Mixing traditional and social logins
  • Temporary users
  • User account FAQ
  • Other ways to learn

Was this helpful?

  1. User manual
  2. Data

User accounts

This article covers how you create and manage Users in your app

Last updated 3 months ago

Was this helpful?

In this article, we're going to explore how Bubble 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 user's shopping cart for example).

  • Privacy rules treat users differently from 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.

What is a user account?

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, registered users or both. This article focuses on registered users – that is, users that have signed up with their email and a password or 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 their 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.

Built-in fields

In addition to the four on all data types, the user also comes with three additional fields:

  • Email

  • Password (invisible)

  • Email confirmed (invisible)

These fields have the following properties:

Email

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.

Password (invisible)

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.

How passwords are kept safe

Bubble ensures the safety of user passwords through the use of and . With this method, passwords are converted into a hash that cannot be reversed back to its original form, even if someone gains access to the Bubble database.

The password is checked by taking the password input provided by the user upon login, hashing it, and comparing it to the hashed password stored in the database.

It's important to note that Bubble only focuses on the match between the two hashes, without actually knowing what the original password is. As such, even we do not have access to the user's original password.

This method of one-way hashing and salting is widely regarded as the best practice for password storage

Email confirmed (invisible)

User actions

Signing up

While the technical process of signing up is handled by Bubble, the design and user experience is entirely up to you.

The sign up action

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.

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.

Video lessons

Logging in

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.

Signing up and logging in with an SSO provider

An SSO provider is a third-party service that you can use to let users log in. For example,

OAuth - signing up and logging in with a third-party service

The most common way to authenticate users is to prompt them to enter a password or an email. However, sometimes, you you will be using some external service 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 labeled 'Login with Facebook'.).

Signing up with 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, to 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.

Mixing traditional and social logins

Users in Bubble can use traditional logins and social logins at the same time. There are a few different scenarios in which this could play out. We cover this in the dedicated OAuth article below:

Temporary users

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 exception). 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 relies 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 automatically transfers the temporary data to the newly created user.

Data stored on a temporary user is transferred automatically when the user signs up, but not when they log in.

User account FAQ

How can I help my users log in if I can't see their password?

Can I log users out from sessions across multiple devices?

How long does the user stay logged in?

  • 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 user clears their browser's cookies

Is there a difference between using the Make changes to action and setting the data source to current user and using the Make changes to current user action?

No, there's no difference between the two: they will both let you change any custom field on the user.

Why can't I select the user's email field in a Make changes to the current user action?

Other ways to learn

Video lessons

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 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 it 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: Reference:

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:

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: Article:

Reference:

Article series:

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 or to .

Yes, you can use the 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 action.

It depends on the settings you set in the action:

(those who haven't signed up but have a cookie) will remain active on the same device for 72 hours

If the action is triggered

If the is triggered on another device

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 . 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).

Building a sign-up system
Using the Facebook Graph API plugin
Facebook
OAuth plugins
User Authentication: Bubble Introduction Series [6/10]
Adding User Settings | Build Your First Bubble App [13/20]
How to Create An Account For Someone Else
Building a sign-up system
Temporary users
List of user account actions
Input elements
Send confirmation email
reset the password
generate a temporary one
Log out other user's sessions
Log the user out
Log the user in
Log the user out
Log out other user's sessions
Update the user's credentials
The email confirmed field is invisible in the database editor but you can access its value in an expression as exemplified above.
Bubble handles security and communication with the database, but the user experience is up to you.
In this example we are signing the user up and then sending them to a page called dashboard.
List of user operators