For this series, we are developing an iOS game called “TapMe”. As TapMe is a multiplayer game, it provides registration for the new users and login for the existing ones. In this article, we are going to demonstrate how to handle user registration and login, as well as how to store a player’s information in the database.
The source code for the game is available in the author’s personal Github repo: https://github.com/olgadanylova/TapMe.git
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:
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
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:
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: