668
edits
Labs/F1/Modularity: Difference between revisions
→Background and Browser Web Modules
| (2 intermediate revisions by one other user not shown) | |||
| Line 8: | Line 8: | ||
F1 will be a proving ground for WebMods, but also needs to be its own product. Thus, the complete WebMod architecture is described here, with generic pieces and F1-specifics carefully separated. | F1 will be a proving ground for WebMods, but also needs to be its own product. Thus, the complete WebMod architecture is described here, with generic pieces and F1-specifics carefully separated. | ||
For those web products wanting to implement WebMods, we have written the [[Labs/F1/Modularity/WebMod HOWTO]]. | |||
== Architecture == | == Architecture == | ||
| Line 36: | Line 38: | ||
=== Authentication === | === Authentication === | ||
==== Login ==== | |||
* WMF | F1, or any other WMF feature mediator (e.g. image share), does not get involved in the user's authentication with the WebMod's backend server beyond coordinating the WebMod's UI needs. While WMF will attempt to support all reasonable authentication options, it is expected that most services will choose to use whatever auth mechanism they already use for their site, eg, cookies. For example, logging out of the site using the normal web UI will also log them out of the WebMod, while logging in via the WebMod mechanisms described here will also log them onto the site for the normal web interface. | ||
** a user- | Specifically: | ||
** | |||
* When WMF receives a "need-to-login" message from the WebMod, it opens up a pop-up to the WebMod's preferred login URL | * WMF messages the WebMod's IFRAME with a ''getLogin()'' call to obtain its login status, passing in a credentials blob it obtained earlier (or null if no such blob exists.) The WebMod may return either: | ||
** Information about the currently logged in user. This information has 2 parts: | |||
*** User information returned in Portable Contacts (PoCo) format. This includes information such as their display name, username, preferred avatar, etc. | |||
NOTE: It isn't clear PoCo is the correct choice here. At a minimum we | |||
probably need fields beyond what PoCo offers (eg, URL to the "my account" | |||
page, etc) so we at least need to spec them and also spec which of the | |||
PoCo fields we will actually look for. | |||
*** An optional user-credentials blob which may be stored by the framework. This blob will never be introspected by the framework (ie, it really is a blob) but will be passed back in subsequent ''getLogin'' calls. | |||
** A "need-to-login" json object. This object may contain multiple supported login methods, but in the first version the only supported method will be "dialog", where a service supplied URL is opened in a popup Window. | |||
* When WMF receives a "need-to-login" message from the WebMod, it uses the "need-to-login" object to initiate the auth process (eg, it opens up a pop-up to the WebMod's preferred login URL) | |||
* The WebMod is then responsible for authenticating the user however it sees fit, in its own HTML content window, likely by prompting for username and password. (That said, OpenID, OAuth, Verified Email, client-side certs, ... can be used at this point.) | * The WebMod is then responsible for authenticating the user however it sees fit, in its own HTML content window, likely by prompting for username and password. (That said, OpenID, OAuth, Verified Email, client-side certs, ... can be used at this point.) | ||
* Once a user has successfully logged in, the WebMod messages WMF back with an optional opaque ''credentials'' JavaScript object, which WMF stores securely | * Once a user has successfully logged in, the WebMod messages WMF back with an optional opaque ''credentials'' JavaScript object, which WMF stores securely. | ||
* WMF then messages the WebMod IFRAME with a '' | * WMF then repeats this process - ie, messages the WebMod IFRAME with a ''getLogin()'' call including the ''credentials'' object it received and stored. The WebMod should, at this point, respond with the user information object (presumably with the same credentials blob it was passed) | ||
The use of the credentials blob is designed to allow WMA to securely store information on behalf of the WebMod if the WebMod desires. However, some WebMods may not wish to take advantage of this (eg, they choose to use the existing cookies provided by the service, use localStorage directly, etc), in which case the WebMod is free to ignore this (ie, never return credentials and therefore always have null passed as the credentials object) | |||
NOTES: | |||
It isn't clear the above actually deals with multiple users per service. Eg, | |||
How is the UI built to switch users and what API calls does that UI make? | |||
Is the added complication of the 'credentials' blob worth while? Existing | |||
sites manage to handle auth without a special secure storage helper - why | |||
can't WebMods just use those existing practices (and update to better | |||
practices as they become known and rolled out for the site itself)? | |||
If the credentials blob is a true blob (ie, may contain binary data) then | |||
some consideration might need to be given to passing this around. I suspect | |||
we want to define this as a simple string, and therefore force the WebMod | |||
to do its own encoding before passing it back to us. | |||
==== Logout ==== | |||
The WebMod will also expose a ''logout'' method which will be passed the most recent 'credentials' object returned by the service (or null if no such object exists). This should always succeed and no scope for a UI is provided (ie, the service can not request a logout page be shown). | |||
After calling the logout method, WMF will delete the credentials blob. Thus, if the WebMod implemented authorization such that only the credentials blob is used, the logout method could be a no-op. If the WebMod implemented auth by way of cookies or by direct use of localStorage, it could simply delete the relevant cookie/storage. | |||
==== Backchannel ==== | |||
The login process above indicates the WebMod's login page must message WMF on successful login. The following considerations apply here: | |||
* How is this defined and how is the WebMod expected to implement it? Will a simple postMessage to window.opener be sufficient? How would the receiving origin be specified? | |||
* What if (eg) Twitter wants to reuse it's regular login page for this rather than a specific page for WebMods. Would they find it reasonable to change their default page to perform this action? If anyone felt there are security concerns in the default page doing it, wouldn't such concerns exist in the WebMod version of the page anyway? Is there any reasonable way we could notice the login in the absence of such a notification? | |||
TODO: The backchannel stuff above needs thought, particularly in the added | |||
overheads it may force on such pages - eg, login pages may not want to | |||
include the jschannels library. | |||
== F1 WebMod APIs == | == F1 WebMod APIs == | ||