Revision as of 11:43, 30 July 2014

Overview

Orion supports plugins that require authentication: for example, a filesystem plugin might require authentication before it can write to any files. The authentication contract is based on a few key points:

• Plugins can be associated with a login page
• Service calls may fail because the user is not authenticated
• The login page authenticates a user with a plugin

Details

When a plugin is loaded, it registers headers with the framework by calling new PluginProvider(headers). Among the headers, it can provide a login field. The login field gives a URL that, when visited by the user, allows the user to somehow authenticate with the plugin. Orion doesn't mandate any particular authentication technology: anything can be used, so long as the contract with the framework is upheld.

The login page need not be unique to the plugin: for example, in the default Orion Java server installation, logging in to the login page LoginWindow.html will set a session cookie that authenticates the user with many plugins in one shot.

When the framework performs a method call to a service provided by the plugin, the plugin can signal to the framework that the call failed because the user needs to authenticate. To do this, it rejects the service call with an object having a status: 401 field. For example:

function writeFile() {
    var d = new Deferred();
    if (notLoggedIn) {
        d.reject({ status: 401 }); // error 401 (unauthorized)
    } else {
        /* write the file */
        d.resolve();
    }
    return d;
}

The Orion UI has special handling of rejected service promises with status == 401. When one occurs, the UI displays a message like this containing a link to the plugin's login page:

The user is then expected to navigate to the login page, log in, and then return to Orion and retry the action they originally attempted. This time, the plugin should perform the action successfully.