The User Type

Bubble makes the assumption that your application will rely on a user management system, i.e. let users sign up, login, log out, to take some actions in your app. Therefore, each new Bubble application has a built-in User type, that follows the same principles as described above, but with a few additional properties. If your application doesn't use users, this will not impact your application.

Difference between the User type and other types

The User type behaves in a very similar fashion to other types that you define in your application. For instance, you can modify a user, delete a user, list them in a repeating group, etc. However, there are a few key differences. Users can be used to handle sessions and authentication in your application. In other words, the User type can be used to know who is currently using the application.

A user is uniquely defined by its email, or its ID if the user is authenticating through an external service (such as Facebook OAuth, see below). Therefore, a user isn't created through a "Create a new thing action', but instead through the 'Sign the user up' or the 'Create an account for someone else' action. Going through such an action in a workflow (in run mode), will create a new thing of type 'User', and will validate the uniqueness of the email. If the user goes through a 'Sign the user up' action, the user will be able to enter a password, while if you use a 'Create an account for someone else', the user will be marked as 'temporary password' and will be prompted to modify his password if you have defined the relevant parameter in the Settings Tab. This setting lets you pick a page to redirect users that haven't entered their own password yet and lets you built a form (with the associated workflows) that let users define their own password. Redirection happens on page load and not after 'Log the user in' action.

The User type has a few built-in fields that you can use in your application. The most important and common will be the 'email' field, that contains the email the user used when he/she signed up, or the first email that can get fetched from an external service if you're using an external service to authenticate users (Facebook, see below). A second field is 'email confirmed', which is a way to know whether the user clicked a link to validate the ownership of an email account. This fields returns a yes/no value.

Note that once a user has been deleted through a 'delete thing' action, this user will not exist in the database any more, and will not be able to log in, etc.

Concept of current user

One of the most important data sources you can use is the 'Current user'. This describes the user that is currently using the application (versus another user in the database). A session is what describes the concept of a user using the application as a given time. Technically, a session is defined by some cookies at the browser level. Depending on your app settings, you can set an expiration on these cookies. In general, such cookies are infinite, and therefore a user will be in the same session until he logs out, or clear the cookies (similarly to Facebook, you are logged in permanently until you log out or use a different browser).

Depending on the situation, the current user can be a registered, signed up user or a temporary user.

Signed up users

If a user has signed up to Bubble (with an email and a password), a permanent entry is created in the database using this email and password. When a user opens your app in a new browser (without cookies) and enters his credentials through a login workflow, he will be logged in. The value of 'Current user is logged in' will return yes. If you modify the current user, this will be saved permanently on the database object, and if the user logs in on another device, he/she will have the changes applied to his account there as well.

One important consequence of this is that all users that can be found through searches in the database will be marked as 'logged in' on the server, as they are permanent accounts.

Temporary users

As soon as a Bubble app is opened in a browser, a user session is created. If a user already logged in and hasn't cleared the cookies, the session will be using the same user as before, but in the case of a fresh session (without a logged in user), a temporary user will be created. This user will be marked as 'not logged in' (in other words, 'Current user isn't logged in' will return yes.

The temporary user behaves like a signed up user, in the sense that you can modify it, and it will be saved to the application database. If a user comes back using the same browser and hasn't cleared the cookies, any value that you have used to modify a field on the user will be the same. Bubble automatically clears temporary user data though. After three days, such a user will be deleted, and when a user opens a session in the same browser, a new temporary user will be created, for three days.

When a user first visits an application, he will be seen as a temporary user. If he goes through a sign up workflow, the current, temporary user will be fore a signed up user and will be saved permanently in the database. This has some important consequences in terms of workflow design. Imagine you have a worflow that asks a user for his/her age before he/she signs up and saves it to the 'Current user'. If the user effectively signs up within three days, the permanent user that will be created then will have the same 'age'.

Using external services to authenticate

The most common way to authenticate users is to prompt them to enter a password or an email. However, very often, you will be using some external services to authenticate users using them credentials from another service. This is done through plugins. Doing so has a few advantages when you design your app. We'll use Facebook as an example below (in other words, your app offers a button 'Login with Facebook'.).

  • This lets your users authenticate faster to your app, and they don't need to remember another password. Usually, most service offer a straightforward, one-click authorization flow to authorize an app to use their identity with them. For instance, you will need one bubble 'Login with Facebook', and the user will be prompted by Facebook to authorize your app to use their credentials.
  • This also lets you make some calls to the service on behalf of the user. With Facebook, this lets you fetch his email (registered with Facebook), get his profile pictures, post on his wall, etc.

When you set up such a flow in Bubble, you will need to define the level of authorization 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 third party application using their credentials, but you can ask for more permissions (for instance post on their wall).

Note that you should only use social logins and ask for permissions if you need them. Asking for permissions to access some data is something that users are sensitive to, and can lead to less sign ups.

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 his password (since he didn't define one), but by logging in with Facebook. If a user is logged in with Facebook in a browser, and if your app uses Facebook log in, the user is automatically logged is as the current Facebook user.

Users in Bubble can use traditional logins and social logins at the same time. There are a few cases here.

  1. 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 Oauth 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 Oauth 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.
  2. If the user isn't logged in when he goes through an Oauth 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.
  3. 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 Oauth credentials and will the email and password values to the user object.

results matching ""

    No results matching ""