Labs/F1/Modularity/WebMod-API: Difference between revisions

Jump to navigation Jump to search

Labs/F1/Modularity/WebMod-API (view source)

Revision as of 02:10, 10 June 2011

3,302 bytes removed ,  10 June 2011
point auth discussion at WebMod spec
(another pass)
(point auth discussion at WebMod spec)
Line 5: Line 5:
== Authentication ==
== Authentication ==


'''Note: ''' This section is just ideas from markh.  Alternative ideas can be found at http://etherpad.mozilla.com:9000/howa.  Further, authentication is so fundamental that the agreed authentication spec should be formalized in the OWA specification rather than the F1 specification (ie, this section should be moved!)
Authentication is all performed by the WMF library - see [[Labs/F1/Modularity#Authentication]] for details.
 
The APIs used for authentication also provide the functionality for obtaining information about the user, such as their name, favicon, etc.
 
To be implemented by the app (ie, APIs called by F1)
 
=== getUserInfos() ===
 
Returns an object with <tt>users</tt> and optionally <tt>login</tt> attributes.
 
<tt>users</tt> is a ''list'' of infos for each logged in user to the service.  If the list contains more than 1 item, multiple accounts against that service are being used (eg, 2 twitter accounts are configured).  The user-info will include some pre-defined fields (eg, name, username, avatar, logout/revoke related links, etc) and any other values the service desires.  The full user info (including the service specific "blobs") will be passed back into the service for many future operations.
 
Note that these user infos are not stored by F1 or the browser - but the app itself is free to manage the storage of credentials etc itself.  Thus, the service specific data should not contain the credentials but instead could be used to identify the user when multiple accounts are supported (eg, it may store an internal "user id" used internally by the app to locate the specific credentials.)
 
Optionally, the return value will include <tt>login</tt> object, itself with a number of attributes which specify alternative login methods.  Eg, a <tt>dialog</tt> entry can specify a URL which will be loaded in a popup Window created by F1.  Services which only allow one user at a time will only return the <tt>login</tt> object when the list of logged-in users is zero.  Services which allow multiple users/accounts will return this object even when there are returned users.
 
When login is required/desired and a 'dialog' method is supported, F1 will open the popup and establish a postMessage channel between the popup and the invisible iframe, so the login screen and the application itself can directly communicate.  When login is complete, the app itself will be able to communicate this back to F1 (which will then re-execute this request and presumably get an extra user in the returned list, and adjust the UI accordingly)
 
==== Example ====
 
In these examples, we assume the service only uses a popup-based login technique.  If no users are currently logged in, the result might be:
 
  {users: [], login: {dialog: 'https://example.com/login'}}
 
If one user is logged in and the user only supports a single user, the result might be:
 
  {users: [{name: 'Joe Blow', userid: 'joeblow', favicons: [...]]}
 
If one user is logged in but the service supports logging in multiple users, the result might be:
 
  {users: [{name: 'Joe Blow', userid: 'joeblow', favicons: [...]], login: {dialog: 'https://example.com/login'}}
 
To be implemented by F1 (ie, APIs called by the app)
 
=== userInfosChanged() ===
 
Inform F1 that the list of logged-in users for the app has changed. F1 will refresh the service by calling getUserInfos() and adjust itself accordingly - eg, by creating a second visible iframe for the service if a new user appears, or displaying special UI if no logins exist at all.


== Sharing ==
== Sharing ==
Mhammond
Confirmed users
99

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/317658"

Navigation menu