The Session

Before we get started on the specifics of how to set up roles and authenticate based on roles, perhaps the best thing to do is to have a general explanation of how the Session works in Group Control. As suggested earlier, most of these features are extended from Auth Core, which in turn uses Aura.Session, but this helps to explain how it is given specific expression within the Group Control App itself. There are several requests that are able to be called on Session which all serve a distinct purpose.

Concept

So, at its most basic, what the Session is designed to do, is to save a cookie with a login information, so that you can stay logged in for a certain period of time before that cookie expires. Then the session requests will also allow you to see various information about the current user, such as their roles in the current app, the allowed departments, etc. At its most basic, Session controls everything about the data that is requested of the current user. This is all done behind the scenes, mostly in Ember FW GC, so you never need to directly call Session through the adapter, but everything is controlled for you.

Usage

There are several requests within the Session, which should be mentioned that are added by Group Control, and so each will have a quick description. In most cases, these are called by Ember FW GC, so you will never need to call these for the app, but it is helpful to know what functions are being called when. It is most helpful to know so that you can look at various network requests in your app. The most important Session requests are the following:

  • getUserInfo is the basic GET request that will get the user data for the current user in the current app (which has information such as their roles, departments they have access to etc). This is the base Session GET request, thus in the network it will be a GET request which is called session/?app={appId}. This is called any time the application is loaded to insure the user is properly authenticated. If this fails, the Login page is loaded instead of the main page. Here is an example of the user data you might see returned from this request:
{
    "userId": "bdbowen",
    "nameFirst": "Brian",
    "nameLast": "Bowen",
    "namePref": "",
    "email": "bdbowen@olivet.edu",
    "isSecure": true,
    "apps": [
        "bul",
        "chklst",
        "chkm",
        "cstat",
        "empdb",
        "erchk",
        "frm",
        "gc",
        "issue",
        "job",
        "kb",
        "msgc",
        "pos",
        "pwd",
        "sa",
        "sstat",
        "sta",
        "sub",
        "tally",
        "wchd"
    ],
    "roles": [
        "global-admin"
    ],
    "departments": [
        "info"
    ],
    "currentDept": "info"
}
  • authenticate is the base login request, which takes a username, password, app, and (optionally) department, and authenticates the user, saving a cookie, etc. This is called by both the Login page and the Re-login modal. It will return the user data for the current app that the user is logging into (same as above). (This is the base Session POST request, thus in the network it will be a POST request that is called session/). For a tutorial on how to call this manually (if using an app like Postman), see this Knowledgebase Entry
  • revoke is the basic DELETE request that will log the current user out. It is called any time the "logout" button is pressed. It will appear in the Network as a DELETE request titled session/.
  • check is a GET request that will return a boolean whether the user is authenticated or not (under the isActive name). It is called every time a new page is loaded (even if the entire application is not reloaded), and will appear in the network requests as a GET request entitled check/.

There are a few other Session requests which are defined by the Router, but they need very little description, and are called only at specific times by the user. They are:

  • change is the request which is called when the user changes department.
  • forgot is the request which is put when you click forgot your password.
  • reset is the request when the user calls the action to reset their password.
  • reload is the request that is called when the user presses reload permissions.

There are other functions defined by the Session Controller, but these are the only functions accessible through the route. While a perfect understanding of the ins and outs of how the Session works is not necessary, these general tips will help to aid you as you seek to understand the apps.