Most of the RainLab User Documentation applies to this as well, since it’s extended over that.

Client-side Integration

Note: Make sure you have finished the client side integration for the mobile plugin first. Any route calls to this plugin’s nodes MUST happen AFTER the installs route request of the mobile plugin. Otherwise, an error may be thrown. On the mobile app, you will have to make a call to the backend using the REST API that has been provided. RIght now, the API works like this:

POST /account/signin

Resource URL: <your-website-url>/api/v1/account/signin

POST /account/register

Resource URL: <your-website-url>/api/v1/account/register

Note: If you have set activation by user in the RainLab’s User Settings then an additional option to set the activation page will appear in the Mobile Login Settings section. This needs to be set as the email sent to user would have to include the activation link.

Custom Providers

By default, the plugin provides a simple provider that allows you to login with username / password and this provider is the one which extends all the Rainlab.User plugin features for mobile login. However, you can create your own login provider such as Social login (using Facebook, Google, etc.), AccountKit, Auth0, etc. or your own custom build login logic. To do this, create a new plugin for this like MyPlugin.MyProviderLogin and in the Plugin.php add a registerMobileLoginProviders function pointing to the provider logic.

    /**
     * Registers any mobile login providers implemented in this plugin.
     * The providers must be returned in the following format:
     * ['className1' => 'alias'],
     * ['className2' => 'anotherAlias']
     */
    public function registerMobileLoginProviders()
    {
        return [
            `Acme\User\Providers\AcmeProvider` => `acme`
        ];
    }

Any custom provider must extend the ProviderBase class. This enforces you to define login and register functions that the plugin needs in order to function. In addition, you may write REST API handlers to handle any specific actions that are specific to the provider you create. For example, lets assume you build a Pattern Login provider (such as the pattern lock in Android phones) and to register user provides name, email and pattern and to login the user provides username and pattern. Your class may require to have an additional function called changePattern to change the pattern by supplying old pattern. This plugin will expose the login and register API routes so you will have to write those additional functions in that plugin’s routes.php file.

In addition, you may also specify extra fields to be taken by the login provider. For example, a Facebook login provider would require Facebook App ID and Facebook Secret Key. You can do this by creating a folder with the same name as the provider and a file named fields.yaml with the usual YAML field definitions like this:

# ========================
#  Extra Field Definitions
# ========================

facebook_app_id:
    label: Facebook App ID
    span: left

facebook_app_secret:
    label: Facebook App Secret
    span: right

If your user specifies login provider as your provider then automatically these fields will be shown.