#61

Product support

Visit this product's website for support.

Categories

  • Developer Tools

IMPORTANT! — Make sure you have purchased the Mohsin.Mobile plugin before getting this.

About Plugin

This plugin is similar to the RainLab.User plugin except it’s built to work mainly with mobile front-ends. It exposes RESTful API nodes that enable interaction with the backend thereby allowing users to sign up and login as front-end users.

Tutorial and demonstration of the plugin:

Features

  • Completely extensible.
  • Compatible with the multiple mobile apps feature of the mobile plugin.

Coming Soon

  • Dashboard widget to provide user signup and register analytics.
  • Forgot password and signing out nodes (Currently, you can do it through website only).
  • Multiple Auth Schemes for better security.

Requirements

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

Parameters Description
instance_id A unique ID, such as device ID or an ID generated using Google’s Instance ID API. Eg. 573b61d82b4e46e3
package The package name of the application. Must match the name specified in the variants. Eg. com.acme.myapp
email (or) username The login attribute for the user attempting to sign in.
password The password for the user attempting to sign in.

POST /account/register

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

Parameters Description
name The name of the user attempting registration.
email The email for the user attempting registration.
username (optional) The username for the user attempting registration.
password The password for the user attempting registration.

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.

1.0.4

Custom login providers can now define extra fields

Nov 21, 2016

1.0.3

App variants can now disable user registrations.

Nov 16, 2016

1.0.2

Minor Bug Fix

Nov 12, 2016

1.0.1

Initial version

Nov 03, 2016