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 data 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.
The User type behaves in a very similar fashion to other data 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 data 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.
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.
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.
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 become 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 workflow 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'.