Skip to content

A2 Applications

Cristina Alonso edited this page Apr 18, 2018 · 5 revisions

Overview

Applications are different services used by this module to manage their users authentication and authorization. For instance, the Analytics back-end or the front-end are applications that this module uses. In order to use them, they have to be registered (hooked up) correctly.

From the administration view in A2 we can see the list of configured applications:

applications list Figure 1.: A2 allows to see the list of configured applications and their information.

Details

To register an application a set of fields must be specified: a prefix that identifies the application (e.g. gleaner) to avoid problems between applications routes; a host base route for their services (e.g. http://localhost:3300/api/) and the roles, resources and permissions needed (in the example of the back-end there are students, teachers and developers). An application can also pass routes that are not protected (unidentified users can access them).

All this information about the application is needed by this module in order to be able to correctly forward the requests received to the correct application. The registered applications have the following fields:

  • Name: a name given to the application.
  • Prefix: a word used to differentiate between applications resources if they have the same roles. The application prefix must be a unique string.
  • Host: the application host. The host must also be unique within all the applications.
  • Roles: needed by the applications in order to work properly. They include:
    • Resources: the role resources.
    • Permissions: the resource permissions.
  • Routes allowing unidentified requests: routes accessible without authentication. This can be a useful feature for applications that want to receive requests to some routes by not authenticated users.
  • Auto-roles, an array of roles that can be used to # the users.

When an application is hooked up we can make request from a front-end (or client) to the application across this module. This way the application will have authentication and authorization. Also, all applications used by the module will have the same users' database, so any user of the back-end can use the same account in other registered applications.

Clone this wiki locally