Jun 22, 2022·1 min read

How to Identify the Current User in AppMaster

Why do we need to know the current user?

When your application is running, you often need to know who is running certain processes. This is necessary in order to correctly distribute data and grant or restrict access to different resources. This feature is used in almost every application.

How to identify the current user in AppMaster

On the backend side

There is an Auth: Get Current User block in AppMaster to detect the current user. It is provided by the Auth module. You can find it in the business-processes editor in the backend tab on the left.

This block returns a record from the User database that belongs to the user who ran the block.

Important

The Auth: Get Current User block works only for authorized users. In all other cases, the result of this block will be undefined.

With this simple method, we can get the current user of our application. However, this block only exists in the backend, but in most cases, it is required to identify the user in the application’s frontend.

On the frontend side

To run processes in the backend from the frontend the endpoints are used. You can find more information about them in this article.

For the Auth: Get Current User block, you need to create a new endpoint, as it is done on the screenshot below:

To invoke the endpoint from the frontend, the Server Request GET /user/get-current block has to be used (in this current case). The endpoints usage flow of the endpoint is the same for web and mobile applications.

Working with the current user

Let's see some examples of the Auth: Get Current User block usage. The block itself returns a record from the User table. In order to get specific data from the record, you need to expand this record with the Expand User block:

All the fields from the output can be used in a specific way. For example to check if the user account is confirmed the Confirmed field of a boolean type can be used as in the image below.

Parameter With

With parameter in the output specifies if the request has to be performed with the use of related tables. So, for example, to get data from the User Sessions table for the current User object (that is a list of current user sessions), you need to specify the value for with field to search for the associated table (User Sessions in this case).

Important!

The With parameter complicates the query and therefore increases its processing time. It is not used by default and is used only if necessary.

Conclusion

In this article, we learned how to determine the current user of the application on the backend side and on the frontend side. This function is one of the most frequently used in application development. With AppMaster, you can perform these requests easily with a few combinations of business process blocks.

FAQ

Use the Auth: Get Current User block in a backend business process. It returns the User record for the person who started that process.

The block needs an authorized user. If someone calls it without signing in, it returns undefined, so handle that case in your process.

Create a backend endpoint that uses Auth: Get Current User, then call that endpoint from your web or mobile app. The frontend does not use the block directly.

Use the Server Request block for the endpoint you created, such as GET /user/get-current. The same endpoint flow works in web and mobile applications.

Add an Expand User block after Auth: Get Current User. It exposes the individual fields from the returned User record so you can use them in later steps.

Expand the User record and use its Confirmed Boolean field in a condition. Your process can allow the action, show a message, or send the user through account confirmation.

Use the With parameter when you need records from tables related to the current user, such as User Sessions. Set it to the related table you need for that request.

It can slow the request because AppMaster also loads related-table data. Leave it empty unless your process actually needs those records.

Start by getting the current user in a backend process, then return only the fields the screen needs through an endpoint. This keeps user checks in one place and gives the frontend a simple request.

If the result is undefined, treat the request as unauthenticated. Stop access to protected data or direct the person to sign in before running the protected action.