| Re: [orion-dev] Other languages/Security |
Hi Tom,
I'm working on a white paper that should help fill in these sorts of documentation gaps but for now...
...as far as security applies to a plugin -- a plugin is isolated in an IFrame (or WebWorker once we add support) and we rely on the browsers built-in "single origin policy" restrictions to prevent a plugin from "directly" calling code or altering the hosting page (e.g. Orion). Instead interaction is handled by having a plugin implement the interface for services that the hosting page can call and it's then up to the hosting page to use the result data to alter the page. Sort of a don't call me we'll call you model.
In many cases a plugin might require authentication and this is handled by the service in the plugin throwing an authentication exception and returning the URL of a page where the user can authenticate. How the plugin actually goes on to authenticate a user or task is then left up to the plugin's authentication page. For example a new user might need to perform a registration step before ultimately logging in. Once the user is logged in the authentication provider can (optionally) notify Orion using a redirect page. One important point is that it is up to the plugin to retain the authenticated user's credentials or a "handle" to the credentials; as a design point Orion host pages do not store plugin credentials in either the client or server and do not perform the authentication directly.
Some of this is still in flux and so not carved in stone but hopefully this helps.
-Simon
tom potts ---11/26/2011 05:42:22 AM---Can anyone give me pointers as to how to configure for other languages in the editor as I'd like to
From: | tom potts <madtom1999@xxxxxxxxx> |
To: | "orion-dev@xxxxxxxxxxx" <orion-dev@xxxxxxxxxxx> |
Date: | 11/26/2011 05:42 AM |
Subject: | [orion-dev] Other languages/Security |
Sent by: | orion-dev-bounces@xxxxxxxxxxx |
