Introduction

Application is the top level entity in the platform. It is the container for all the resources used in the application. It provides the ability to manage the resources and the users who can access the resources via various roles and permissions. With in the security module there are other entities like Packages, Roles and Permissions which are sometimes related with the application and client and other times they stand on their own. For example a Role can be created which stands on its own when roles are created by SYSTEM client (more on this later in the Client section) but in general roles are created by any other client are related to an application.

When an application is created by a client, that client is the owner of the application. They get to do all the operations like create, update, delete, manage the resources in the application.

Creation

An application can be created by any user with the authority Authorities.Application_CREATE. The basic information it requires to create an app is

• Name: Any name that represents the application.

• Code: A unique code that represents the application. This code is used in the URL to access the application. It is also used in the API to access the application. If one is not provided it is generated based on the Name of the application.

• Type: Currently we are supporting two different app types, APP and SITE. APP is a regular application that has server side logic and SITE is a website or a landing page that does not have much of server side logic except for occasional storage of a contact form or integrating an API or adding analytics like Google Analytics or Facebook Pixel.

• Access Type: This is used to define the access to the application. Currently, sports OWN, ANY and EXPLICIT.

  • OWN: Application with OWN access type can only be accessed by the owning client. If someone or some client need to gain access to the application either write or read, it can be granted by either the owning client or the SYSTEM client. One another way is to provide registration on the application then the client created by this registration process will give read access to the application.

  • ANY: Application with ANY access type can be accessed by any client who are being managed by the client which created the application. They just have to call the API to add access to the application either read or write.

  • EXPLICIT: Application with EXPLICIT access type is used for the applications which are being imported into the system from marketplace. When we import an application from the marketplace, the application is created with EXPLICIT access with the client who is managing the importing client as the owner. This provides us a way to manage the application resources in a way that the client who is importing can upgrade the application without loosing their changes.

• Thumbnail URL: A URL to the image that represents the application. This image is used in the UI to represent the application.

• Client ID: The client for whom this application is being created. If nothing is provided, the logged in client ID is taken as the client ID. If the application is being created for some other client then the logged-in user's client should be either a SYSTEM client or the client that is managing the client for whom the application is being created.

Concept of Inheritance

Everything in this platform is based on the concept of inheritance with very few exceptions like the security items. The inheritance is used to provide the ability to manage the resources in a hierarchical way. If an application is created and given edit access to another client, they can make edits to the application and the resources in the application without losing the updates or changes from the owner of the application. This is achieved by the concept of representing the most of the objects in the form of directed acyclic graphs. More on this when we discuss the objects of Core and UI services.

Update

A user should have the authority Authorities.Application_UPDATE to update an application. Application name, access type, thumbnail URL are the only details one can modify even they are SYSTEM level client. The people who can update an application are SYSTEM client users or the users of the client who created the application or the users of the client who is managing the client for whom the application is created.

Removal

A user should have the authority Authorities.Application_DELETE to delete an application. All the rules applied in Update will also be applied here. While removing an application or the associated objects like packages, permissions, roles, authorization accesses, URLs, client certificates, app dependencies, properties, registration accesses, registration package and user roles should be removed before deleting the application.

In the multi-server, we are providing the REST end point to clean up all the associated objects of an application in one go. This service would connect to all security, CORE and UI servers to provide this clean up. This service is partially completed which needs a second look.

Properties

We are providing a mechanism where an application can be attributed with pre-set properties.

1. REGISTRATION_TYPE - This property holds the type of registration for a given app which can be configured at a client level.

• Registration through code is used when you want to generate a code for sign-up.
• Registration through immediate log-in is used when there is no need for any verification and is taken directly to the home page/screen.
• Registration through email verification is used to verify the email immediately after sign-up.
• Registration through OTP verification either through email or phone number text message.

2. URL_SUFFIX - This property is used to hold the suffix of the URL after registration. For example - in CX app, after a business is registered - we create a subdomain URL. This property is configured with Stage.Modlix.com based on the environment it is deployed in.

3. URL - This property gives you the URL of an application at a client level. This is only required if you are overriding the auto generated or configured URL in the system. ATTACH AN EXAMPLE

Read Access

For any client to log-in into an application, one would require Read Access. This can be provided either by system client or the application owner. OR anyone who has the write access to the application. Other the login privileges, Read Access will only provide definition read functionality for all CORE and UI objects.

Write Access

By default the creator of application will gain Write Access. All others need to gain this access explicitly either from system client or application owner. Anyone other than owner editing the CORE, UI or Security objects will create a delta but wont change anything that is provided by the owner of application. This ensures the "concept of inheritance".

Dependency

Application dependency is a concept which allows to usage of objects from the dependent application in the client's access range. For example - in CX app, we use KYC as a dependency which let CX App consume UI and Business Logic. To add an App as a dependency, one has to be the owner of the application. It cannot be added just because one has write access.