The way this scheme works is: when a plugin registers headers with the framework — by calling new PluginProvider(headers) — among the headers, it can include a login field giving a URL that, when visited by the user, allows them to somehow authenticate with the plugin. Orion doesn't force any particular auth technology here, it's up to the plugin and its login page to figure that out.
To signal to the framework that the user needs to authenticate, the plugin can return a 401 "unauthorized" error from a service method call, like this for example:
function myServiceMethod() {
var d = new jQuery.Deferred();
if (notLoggedIn)
d.reject({ status: 401 }); // error 401
else
d.resolve( /*...*/ );
return d;
}
The Orion UI has special treatment of status == 401 that recognizes it as an auth failure, and displays a link to the plugin's login page. The user is expected to go there, log in, and then retry whatever they were doing.
So, in answer to the questions from your earlier message:
1) You can't force a login before the plugin is loaded and registered. But the plugin can simply reject every call with a 401 error until the user has logged in.
If the plugin can't even be fetched before authenticating — if your server returns a 404 page for example — it's considered a timeout by the framework, and the plugin will be disabled until the user refreshes the page.
2) No. The Orion UI doesn't know anything about the authentication scheme that the plugin and its login page are using, so it is not aware if the user changes. The only lifecycle integration point is that a service call can be recognized as "failed because you weren't authenticated".
3) No… This really should be documented, but I couldn't find any material on the Orion wiki.
Mark
