Suppose your app logs in a user. As a result, the app gets user-token which uniquely identifies the user’s session with Backendless. If your app uses our SDK for Android, iOS, JS or .NET, the user-token value is managed directly by our libraries. Specifically, it is added to every API call to maintain the session and tell the server about the user’s identity. There are situations when you need to get the user object when your app has only user-token. This could happen if you used persistent login in the application, which stores user-token on the device. The implementation does not save the user object, however, there is a way to retrieve the user based on the user-token value (assuming the token is still valid). In this article, I will show you how to do this.
The technique for retrieving the user object is creating an API service which accepts a user-token in the header and retrieves the current user. I will use Codeless to create the API service because it has an intuitive interface and allows you to solve these tasks very quickly, just by building the algorithms instead of writing code:
We supported Google Sign in for a while, however, the feature was not properly documented. Not anymore )) The documentation has been updated for Android and iOS SDKs. Using the “Login with Google” function, an app can provide a way for the users to login using their Google credentials. Once a user is authenticated, Backendless creates an internal account and starts a logged-in session.
See Backendless documentation for details:
We conducted a webinar titled “Backendless Core Concepts” for ex-Parses last week. A recording of the webinar is now available. The video should be helpful not only if you’re coming from Parse, but for anyone who is starting their journey with Backendless. The webinar reviewed the concepts of Backendless User and Data services. Specifically, we focused on:
- user properties
- setting up user relations
- registering a user
- registering a user with custom properties
- configuring a data model
- code-driven schema creation
- data relations
- a brief overview of Cloud Code
Previously I wrote about the API to send a temporary password to a user (restore password). With the free plan the API sends a password generated by the backend system. However, with a paid plan, the same API works differently. Rather than sending a computer-generated password, user receives in an email a link to a customizable page where they can choose their own password. The webpage which Backendless uses by default is loaded from the file storage allocated to your Backendless backend. You can see it at the
/web/templates/change_password/ directory:
In my previous post I described how to send a temporary password to a user when he cannot login. A password is delivered in an email message. The message can be customized using Backendless console:
- Login to Backendless console, select your app and click the Users icon.
- Click the Email Templates menu.
- Select User requests password recovery from the drop-down menu.
- Modify the email template text using the built-in editor.
- You can preview the email using the Preview button. When you are done save the email template using the Save button.
Previously I wrote about changing user’s password by administrator or via API if user can login. There is also a scenario when a user needs to change password when he cannot login for the reason that the password is forgotten. In this case, Backendless provides a simple API that delivers a temporary password to the user’s email address. The email message can be customized by editing the template for the ‘restore password’ event. This behavior is specific to the apps on the free plan. Applications on the Backendless Plus or above plans provide more flexibility for resetting user’s password.
When a user registers or update his account, application uses the user registration API. It is common for the user interface to enforce the data entry rules and validate the values entered by the user. However, an alternative approach is to perform data validation on the server. Backendless supports user properties validation on creating and updating user objects using regular expressions. Backendless console includes several pre-configured regular expressions for the most common data types, such as email address, URL, social security number and US phone number. Additionally, app developer can specify their own regex. To configure a validator for a user property:
The logout API is a logical counterpart for the User Login API. The logout step is not required for most apps – user session will expire automatically. However, some apps provide the functionality, especially those with a special multiple login policy. The logout API is very simple – a single line of code terminates the current session:
Previously I wrote about enabling email address confirmation for the app users after they register and before the login. The feature sends out an email with a link a user must click in order to confirm his/her email address. The text of the email can be easily customized:
- Login to Backendless console, select your app and click the Users icon.
- Click the Email Templates menu and select Confirmation template from the drop-down menu.
- The console displays email text editor:
Once a user of a Backendless-powered app logs in, a session is established. The session has an inactivity timeout that is reset with every new API call made within the session. The default timeout value is 3600 seconds (1 hour). It means Backendless will keep a session alive 1 hour after the most recent API request. The inactivity timeout value is configurable in Backendless console:
The Enable Session Timeout configuration is located under Users > Login. The default setting if the configuration property is OFF. In that case, the inactivity timeout is set to 3600 as described above. To change the setting, enter a timeout value in the inactivity timeout textbox and click the toggle to set it to the ON state. The maximum allowed value is 30 days, which is 2592000 seconds.
