Cleeng login Plugin (by OPT) – Applicaster Support

Introduction

This Document explains the configurations and what is supported in the Cleeng login Plugin, created and supported by Applicaster's OPT (Official Plugins Team).

This Cleeng Login plugin, as opposed to the older legacy ones, is bases on the CAM Framework (Content Access Manager). This means that unlike the previous plugin which was based on content strictly promoted in the Applicaster2 CMS, this new plugin Supports the following Content Sources:

Content originating from the Applicaster2 CMS
Content coming in the form of Feeds via a DSP (Data Source Provider)

The main purposes of the Cleeng Login Plugin, is to:

Manage End-users
Manage Login Flow
Manage Purchase Flow
Manage purchases on the User level

Flow of how Login and Purchases is done in this Cleeng Login Plugin, when using Applicaster2:

i - VODs appear as Locked -

They are promoted in Applicaster2 as "Not Free" and have an Authorisation provider attached to them.

As such, the items will appear with a Lock icon.

ii - Login Screen -

Once a Not Free item is clicked upon, this will popup the Login Screen (which is configured as a Screen Hook):

*NOTE: The doc states that tapping on a Locked Icon, opens the Login Screen, but this of course depends on the the configurational fields, that are set in the Configuration JSON file:

Authentication Requirement, and
Default Authentication Screen

For example:

"Login": [ { "type": "EMAIL", "key": "email", "title": "Email", "hint": "Email", "mandatory": true },

Default Authentication Screen:

Authentication Requirement is not set to “Never require”

Tooltip
- When the authentication process begins, this field determines what to present first.
- By selecting “Login”, the plugin will prompt login first, with an option to switch to the sign-up screen in case the user does not have an account.
- By selecting “Sign-Up”, the plugin will present the user with the sign-up (aka registration) screen first, with an option to switch to login in case the user already has an account.
Type
Possible options:

Login
Sign-Up
- Select

Default

Below is information on the Login Screen option:

The Login screen was created in a Generic manner via the CAM Framework, and all the Assets, Styles, and even the Fields themselves, are fully configurable via the Login Screen configurations in the UI Builder.

This means that the UI of the Login Screen is not specific only for the Cleeng Login, but rather uses the CAM (Content Access Manager), and thus can be used in a Flexible manner for any login plugin, and for any Provider using this infrastructure.

iii - Configuring the UI of the Screen via JSON File and the CAM Framework:

Input Fields which control the UI (such as texts, localisations and buttons), are configured via a JSON file added to the "Authentication Input Fields" in the Plugin Screen configuration.

The exception to the above, would be Assets, which are uploaded via a Zip file. Zapp doesn’t support uploading the assets via the screen configuration fields, so you have to do it on the plugin itself in the plugin configuration screen.

Sample ZIP assets file to be inserted on the plugin level, for Android -

https://drive.google.com/file/d/1q-908MaVxJyTq11ROH4ZNSouC4w43S_u/view?usp=sharing

Sample ZIP assets file to be inserted on the plugin level, for iOS -

https://drive.google.com/file/d/12FHlYrMVcc1FmB3CV_sutyczgXByoGNl/view?usp=sharing

Uploading the JSON with the UI Input Fields:

Please upload a JSON file with a section for the sign-up and login screens, with each section containing the expected input fields for the given screen. Please follow the format and guidance outlined in the example file [here](https://example.com)

For example, the basic Login Plugin which can be seen above, supports the following Field types via JSON file:

Sign Up
Login
Password reset

This manifests visually in the following UI:

An email
A Password
Sign up button

{ "Sign-up": [ { "type": "EMAIL", "key": "email", "title": "Email", "hint": "Email", "mandatory": true }, { "type": "PASSWORD", "key": "password", "title": "Password", "hint": "Password", "mandatory": true } ], "Login": [ { "type": "EMAIL", "key": "email", "title": "Email", "hint": "Email", "mandatory": true }, { "type": "PASSWORD", "key": "password", "title": "Password", "hint": "Password", "mandatory": true } ], "Password-reset": [ { "type": "EMAIL", "key": "email", "title": "Email", "hint": "Email", "mandatory": true } ] }

By Adding the JSON to the plugin, you can actually dictate which configurations, your plugin will require. The UI, in-turn, is not specific for Cleeng, but rather the UI of the CAM framework, which can be used as a Screen Flow and Logic in Any plugin.

The Authentication Screens (Login, Signup, Reset Password) are configured using a json that describes the fields that will be presented on those screens.

The screens use this configuration to determine which fields will be presented to the user in those screens, the input type (text, number, etc.), and whether or not they are mandatory.

Each json object consists of the following fields:

"type": the type of input field, out of the following options: TEXT, NUMBER, PASSWORD, EMAIL
"key": the key that will be used by the authentication service api to send the contents of the field.
"title": the title that will be presented in the screen UI next to the input field, identifying it for the user
"hint": the hint text that will appear within the field itself, to guide the user on how to fill in the field
"mandatory": determines whether the field is mandatory or not. Fields that are marked as mandatory must not be left empty, and will trigger an alert if the user tries to submit the form without populating them.

Please find here an example of the expected Configuration JSON Structure:

{
  "Sign-up": [
    {
      "type": "EMAIL",
      "key": "email",
      "title": "Email",
      "hint": "Email",
      "mandatory": true
    },
    {
      "type": "PASSWORD",
      "key": "password",
      "title": "Password",
      "hint": "Password",
      "mandatory": true
    },
    {
      "type": "NUMBER",
      "key": "phone",
      "title": "Phone",
      "hint": "Phone",
      "mandatory": true
    },
    {
      "type": "TEXT",
      "key": "gender",
      "title": "Gender",
      "hint": "Gender",
      "mandatory": false
    }
  ],
  "Login": [
    {
      "type": "EMAIL",
      "key": "email",
      "title": "Email",
      "hint": "Email",
      "mandatory": true
    },
    {
      "type": "PASSWORD",
      "key": "password",
      "title": "Password",
      "hint": "Password",
      "mandatory": true
    }
  ],
  "Password-reset": [
    {
      "type": "EMAIL",
      "key": "email",
      "title": "Email",
      "hint": "Email",
      "mandatory": true
    }
  ]
}

iv - Alternative Authentication Fields and Asset Configurations

Additional buttons which are Not Input fields (for example: Facebook Social Login Button), are set up via the "alternative authentication" fields. Here are the requirements:

https://docs.google.com/document/d/1atSODiGKggyc2Sd0OEmRp48XczyVHnmbH97nV0QqWPE/edit?usp=sharing

Text and Styling (Remote) -This also means that the Text and Styling changes are all Remote (runtime), and don't require a new build.

Assets (Zip File upload on a Plugin-App Version Level) - Note that the Assets configuration is still done via the Plugin Configuration, and not via remotely via the Screen Configuration. This is done on a Version level (in the version-level plugin configuration, and not on the UI Builder Plugin level)

[It's a Zapp requirement that the iOS and Android Assets Bundle, Not be Screen-Level Configuration fields]

* A default Zip Asset file is pre-loaded. It's required to click on "Save" and save this default Zip file, the first time you create a build for a version

Please find attached the links to the Text, Assets and Styling keys of the plugin:

Detailed Sketch File -
- https://applicaster.slack.com/files/U2N2SMSV7/FLZP3RPB4/login_plugin_zapp_-_documentation_file.sketch
Plugin Keys -
- http://assets-production.applicaster.com/applicaster-employees/support_team/yona/cleeng/Cleeng_opt_keys.png

v - Storefront screen and Purchases -

Once you complete the login phase, you will see the Storefront and Purchases screen, where you will see a list of available purchases, as configured (in this case), in Applicaster2.

eg: Yearly Subscription, Monthly Subscription, etc...

From here, the purchase is recognised as any other In App Purchase between Cleeng and the Store.

If the purchase has been successful, but the purchase has not been registered on Cleeng's side to allow the end-users to login, the behaviour might be different.

The correct flow is that:

A Successful purchase is made
The Cleeng Web Service (https://applicaster-cleeng-sso.herokuapp.com/) handles the Calls against Cleeng [the Cleeng Web Service is also where the Products are created]
A response is sent to Applicaster2, and the purchase is then registered in Applicaster2 and associated with the specific Device ID and the Product purchased.

If Applicaster2 was not used, and the source of Data was via DSP from Cleeng, then the flow would stop once the purchase has been completed and registered in Cleengs Web Service.

ie: The Cleeng Web Service will still be required to create the products, but Applicaster2 would no longer be part of the process.

Purchases Configuration on an App Level in Zapp

An important point to notice, is that when setting up a version of the app to Support purchases, one must enter the "General Settings" option on the App Dropdown menu in Zapp, and select the "Purchases" checkbox:

vi - Setting up and configuring Products in the Cleeng Web Service -

Web Service Documentation:

Please find below, documentation explaining how to set up and configure the Cleeng Web Service:
- https://applicaster.zendesk.com/hc/en-us/articles/360020621512

vii - Playing the VOD Item -

Once we have successfully surpassed the Login, and then Purchase process, the VOD item will now be playable.

viii - Types of Supported Products:

VOD Items
Live
Anything to which an Auth Provider can attached ...

ix - Unsupported Products and Features:

Link Categories are Not supported. This means for example, that you can't assign an Authorisation Policy to a URL Scheme.
- ie: If a Push Notifications is sent Directly to a Live Channel via URL Scheme, there will Not be a way to call here for any authentication.

Redeem Codes are Not Supported
Logout is currently Not yet supported.

Additional Configurations

Cleeng is designed to work with a broad variety of data source providers and supports a variety of configuration fields to determine when to render authentication and payment screens.

At the same time, Applicaster2 is set up such that certain configurations are handled on its side. The following combinations are not valid as they contradict, and they are not supported by the Cleeng plugin:

Authentication Requirement is set to “Never Require”, Require Payment is switched off, but an item in Applicaster 2 is marked as not free or has an Auth Policy assigned to it.

ignore_default_subsctiption -

This field is required to be checked in order to use the Applicaster Player and Cleeng together. The flag “ignore_default_subscription” on the plugin should be flagged “on”, in order to trigger the login plugin as a hook for the player.

x - Troubleshooting Rule of Thumb:

i- Issues with the UI and Screen Flow -

Usually would be as a result of a problem in the CAM Framework (in this case, manifested in the form of the plugin Configuration Fields).

ii- Issues with the actual Login Process / Sign-In / Reset Password / etc.. -

This usually would suggest a problem with the Cleeng implementation, and thus the Plugin needs to be reviewed with the OPT team.