Native authentication

Livebase’s native authentication system is HTTP Basic for the GraphiQL client and cookie based.

In a HTTP Basic system, the credentials used to authenticate the user travel with each request to the server in a special header, and can be stored by the browser. This implies that logging out is only possible after a period of inactivity or by manually removing the stored credentials on the browser side.

In a cookie based system, when a user authenticates with a server using the HTTP protocol, the server generates a session object and sends, via cookie, the identifier of this object (sessionID) to the client to be stored locally. Each time the client makes a request to the server, it must include the cookie with the sessionID to remind it of its passage. The client sends an explicit request to the server to log out, which invalidates the session object and instructs the client to delete the cookie with the sessionID.

Profiles and Users #

A profile is an identity defined in the engine of a Cloudlet, which is associated with a Profile Schema that lists its permissions on resources, such as applications and objects. By “user” we mean any user registered with the Cloudlet itself.

Each user can only be assigned one profile, giving them all the permissions defined in the associated Profile Schema.

Regular users and default member #

In Livebase, users of a Cloudlet are instances of the __User platform class and live within the Cloudlet Database. The moment this is first generated, a default member is created with the same username and password as the Livebase account currently in use and is assigned the Member profile, which grants full access to all classes in the model except for the __User class. If the database is emptied or deleted, you can create the default member again by first clicking on the and then the Create Member button.

Authentication procedure #

Let’s see in detail the procedure to follow to authenticate with the GraphiQL client of a Livebase Cloudlet.

Authenticating with GraphiQL #

To log in to the GraphiQL client, make sure that the GraphQL API is enabled by clicking on the button and checking that the relevant switch in the API & Public URLs panel is set to On:

Next, open a browser and navigate to the following URL:

https://<CloudletURL>/auth/api/graphql/asset/index.html

If there are no credentials stored, a warning message will prompt for username and password:

Fill in the required fields and click Login: if the authentication is successful, you will see the GraphiQL environment, and you will be able to make calls to the endpoints with the permissions of the user you logged in with; otherwise, the warning message will be shown again asking you to type in your credentials again.

Enabling new users #

In order to enable other users to access the Cloudlet, you need to perform these steps:

• make the __User class visible in the model: this requires including it in the Database Schema and enabling it in at least one application view;
• grant user creation privileges to at least one of the defined profiles.

The first two steps are detailed in the Create the __User class section of the __User class, respectively, and in the Rights of the __User Class section of the Rights (grant) section. The following section details the procedure for logging in and creating new users from GraphQL.

Creating Users in GraphiQL #

Log in to the Dashboard and start a Cloudlet with GraphQLs enabled (see the section Authentication Procedure).

Access the GraphiQL client with the following URL:

https://<CloudletURL>/auth/api/graphql/asset/index.html

Log in as a user with create permissions on the __User class, then submit the following mutation of type create:

mutation {
  _User___create(data : {
    username : <newUserName>,
    profile : <newUserProfile>,
    email : <newUserEmail>
  }) {
    _id
  }
}

The username, profile, and email fields must be filled in with the username, the profile to be assigned, and the new user’s reference email, respectively. You must also specify a list of selection fields, which are the fields of the newly created object that you want to be shown in the response. In the example, only the _id field has been requested.

If the operation is successful, you get a response like the one shown in the figure, and the link to set the password is sent to the specified email address.

{
  "data": {
    "_User___create": {
      "_id": <newUserId>
    }
  }
}