Privacy/Reviews/F1A: Difference between revisions

Jump to navigation Jump to search

Privacy/Reviews/F1A (view source)

Revision as of 00:07, 30 September 2011

834 bytes added ,  30 September 2011
→‎Architecture
Line 53: Line 53:


* NOTE: Initial release of Firefox Share Alpha (Q3 or early October) does not inject the navigator.* APIs into browser tab content.  It is intended that we will re-enable that functionality in a near-future release.
* NOTE: Initial release of Firefox Share Alpha (Q3 or early October) does not inject the navigator.* APIs into browser tab content.  It is intended that we will re-enable that functionality in a near-future release.
The following illustrates how data flows through the system when talking about mediated web activities such as F1.
[[File:MediatedActivities.png]]


'''Other Resources'''
'''Other Resources'''
Line 74: Line 78:
** for has patch from [https://bugzilla.mozilla.org/show_bug.cgi?id=675812 bug 675812] which fixes panel style for osx
** for has patch from [https://bugzilla.mozilla.org/show_bug.cgi?id=675812 bug 675812] which fixes panel style for osx


=== fx-share-addon ===
=== Mediator content iframe ===


F1 is an implementation of a mediator for the share activity.  The mediator content iframe is content
loaded locally from the addon.  APIs (navigator.mozApps.mediator.*) are injected by the mediator class.  Communication between the content iframe and the mediator class are through sdk ports, passing JSON data.


'''Stored Data:'''  
'''Stored Data:'''  


'''fx-share-addon does not store any data, openwebapps addon, installed webapps and oauthorizer store data that fx-share-addon relies on.'''
The mediator stores no data.
 
{| class="wikitable"
|-
! What
! Where
|-
| openwebapps data
| see openwebapps component
|-
| oauth credentials
| see oauthorizer component
|-
| webapp specific data
| see openwebapps component
|}


'''Communication with webapps'''  
'''Communication with service content iframes'''  


fx-share-addon communicates via openwebapps with apps it uses.  The communication mechanism is via the addon-sdk port mechanism.  There are a couple APIs the webapp can call that are globally injected, see the webapps component below.
Communication with service iframes is tunneled through the mediator class.  There is no direct conduit
between the mediator content and the service content (even though the mediator content could directly access the service iframe).


{| class="wikitable"
{| class="wikitable"
Line 109: Line 101:
| ''In:''  
| ''In:''  
| getParameters
| getParameters
| none
| parameter information for ui configuration and oauth
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| getParameters
| getParameters
| parameter information for ui configuration and oauth
| none
|  
|  
|-
|-
| ''In:''  
| ''In:''  
| getShareTypeRecipients
| getShareTypeRecipients
| type of share (e.g. direct, public, group name)
| abbreviated contact data for autocompletion support
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| getShareTypeRecipients
| getShareTypeRecipients
| abreviated contact data for autocompletion support
| type of share (e.g. direct, public, group name)
|  
|  
|-
|-
| ''In:''  
| ''In:''  
| resolveRecipients
| resolveRecipients
| list of recipients user has entered into TO field
| success/error of recipient validation
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| resolveRecipients
| resolveRecipients
| success/error of recipient validation
| list of recipients user has entered into TO field
|  
|  
|-
|-
| ''In:''  
| ''In:''  
| getLogin
| getLogin
| none
| user profile on success
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| getLogin/getCredentials
| getLogin/getCredentials
| user profile on success
| none
|  
|  
|-
|-
| ''In:''  
| ''In:''  
| setAuthorization (1)
| setAuthorization (1)
| oauth credentials
| none
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| setAuthorization
| setAuthorization
| none
| oauth credentials
|  
|  
|-
|-
| ''In:''  
| ''In:''  
| confirm (2)
| confirm (2)
| page data(3)
| success/error of send
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| confirm
| confirm
| success/error of send
| page data(3)
|  
| called when the user clicks "send"
|-
|-
| ''In:''  
| ''In:''  
Line 185: Line 177:
3. page information such as URL, opengraph data, Title, select share image (currently the first one found), etc.
3. page information such as URL, opengraph data, Title, select share image (currently the first one found), etc.


=== webapps installed by fx-share-addon  ===


'''Communication with mediator class'''
{| class="wikitable"
|-
! Direction
! Message
! Data
! Notes
|-
| ''In:''
| x
| none
|
|-
| ''Out:''
| x
|
|
|}
=== service content iframes  ===
For each installed service that supports a given activity, the mediator content creates an iframe.  The mediator class then injects APIs into the service iframe using the addon-sdk worker class.
Currently, F1 does not allow installation of remote services.  It installs three services that are contained in the addon, Twitter, Facebook and GMail.


'''Stored Data:'''  
'''Stored Data:'''  


'''fx-share-addon installs three built-in webapps for Twitter, Facebook and GMail.'''  All three webapps store identical data sets into their own domain specific local storage.
While a service may store any data it wants in localStorage, these are the data that our implementations store.


{| class="wikitable"
{| class="wikitable"
Line 203: Line 220:
| localstorage
| localstorage
|-
|-
| users oauth credentials
| users oauth credentials, secrets, etc
| localstorage (see oauthorizer component)
| localstorage (see oauthorizer component)
|}
|}


'''Communication with F1/OWA'''  
'''Communication with mediator content iframe'''  


* these calls are over add-sdk ports
Communication with mediator content is tunneled through the mediator class.  There is no direct conduit
* these are calls that a webapp service can make which will result in a call into the mediator.
between the mediator content and the service content (even though the mediator content could directly access the service iframe).


{| class="wikitable"
{| class="wikitable"
Line 220: Line 237:
|-
|-
| ''In:''  
| ''In:''  
| service.ready
| getParameters
| app origin
| none
| same as origin in postMessage api
|
|-
| ''Out:''
| getParameters
| parameter information for ui configuration and oauth
|
|-
| ''In:''
| getShareTypeRecipients
| type of share (e.g. direct, public, group name)
|
|-
| ''Out:''
| getShareTypeRecipients
| abbreviated contact data for autocompletion support
|
|-
| ''In:''
| resolveRecipients
| list of recipients user has entered into TO field
|
|-
| ''Out:''
| resolveRecipients
| success/error of recipient validation
|
|-
| ''In:''
| getLogin
| none
|
|-
| ''Out:''
| getLogin/getCredentials
| user profile on success
|
|-
| ''In:''
| setAuthorization (1)
| oauth credentials
|
|-
| ''Out:''
| setAuthorization
| none
|
|-
| ''In:''
| confirm (2)
| page data(3)
| called when the user clicks "send"
|-
| ''Out:''
| confirm
| success/error of send
|
|-
| ''In:''
| logout/clearCredentials
| none
|  
|-
|-
| ''Out:''  
| ''Out:''  
| logout/clearCredentials
| none
|
|}
'''Communication with mediator class'''
{| class="wikitable"
|-
! Direction
! Message
! Data
! Notes
|-
| ''In:''
| service.ready
| service.ready
| none
| none
|  
|  
|-
| ''Out:''
| service.ready
| app origin
| same as origin in postMessage api
|-
|-
| ''In:''  
| ''In:''  
| service.registerHandler
| service.registerHandler
| origin, activity and message
| none
| all strings used by mediator to call a specific handler (e.g. url, "link.send", "confirm")
|  
|-
|-
| ''Out:''  
| ''Out:''  
| service.registerHandler
| service.registerHandler
| none
| origin, activity and message
|  
| all strings used by mediator to call a specific handler (e.g. url, "link.send", "confirm")
|-
|-
| ''In:''  
| ''In:''  
| oauth.call
| oauth.call
| auth service information, user tokens, url to oauth endpoint, parameters (share data)
| results returned by call to oauth endpoint
| for oauth call which are sent to oauth endpoints
|  
|-
|-
| ''Out:''  
| ''Out:''  
| oauth.call
| oauth.call
| results returned by call to oauth endpoint
| auth service information, user tokens, url to oauth endpoint, parameters (share data)
|  
| for oauth call which are sent to oauth endpoints
|-
|-
| ''In:''  
| ''In:''  
| sendEmail.call
| sendEmail.call
| user oauth tokens, share data, recipients list
| simple success/failure object
|  
|  
|-
|-
| ''Out:''  
| ''Out:''  
| sendEmail.call
| sendEmail.call
| simple success/failure object
| user oauth tokens, share data, recipients list
|  
|  
|}
|}


=== openwebapps ===
=== OWA stuff ===


OpenWebApps provides the ability for content to install an "app" which may also include a "services" component using the Web Activities APIs.  fx-share-addon relies on the Web Activities/services functionality for extensibility.
OpenWebApps provides the ability for content to install an "app" which may also include a "services" component using the Web Activities APIs.  fx-share-addon relies on the Web Activities/services functionality for extensibility.
Line 278: Line 376:
| manifest data for apps
| manifest data for apps
| sqlite database
| sqlite database
|-
| app specific data
| webapps may store their own data in their own localstorage
|}
|}


Line 305: Line 400:
=== oauthorizer  ===
=== oauthorizer  ===


OAuthorizer provides simple APIs for initiating OAuth login/authorization flow and calling OAuth version 1 and 2 based APIs.   
OAuthorizer provides simple APIs for initiating OAuth login/authorization flow and calling OAuth version 1 and 2 based APIs.  In our use of oauthorizer, a service iframe makes a call which is received by the mediator class.  The mediator class passes that to oauthorizer which makes the oauth call and returns the response.
 
The addon currently *can* store OAuth credentials in prefs, however it provides a flag to prevent storage of credentials.  The openwebapps addon provides content-available APIs to use OAuthorizer, and passes the flag to prevent OAuthorizer storage of credentials.  openwebapps does not store credentials, but passes them through to the webapp, which stores them in local storage.  The login/authorization flow is *NOT* provided to content directly, it must be initiated from an openwebapps mediator (such as fx-share-addon).  The content-available APIs for making OAuth based API calls requires content to have OAuth consumer and user keys, so without the login flow, it is largely unusable from content.  Those content-available APIs will be removed in the future and made available only to openwebapps services.  OAuthorizer is otherwise only directly accessible via chrome code.


* future changes
* future changes
** remove ability to store credentials completely
** remove ability to store credentials completely
** remove content-available API and make available only to mediated openwebapps
** remove content-available API and make available only to mediated openwebapps
This component does A, B and C and interacts with component Y to do D.
The tables below simply summarize the data encountered by this component.


'''Stored Data:'''  
'''Stored Data:'''  


{| class="wikitable"
While oauthorizer can be used to store OAuth credentials, in our use it does not. 
|-
! What
! Where
|-
| consumer key and secret
| webapp local storage
|-
| user key and secret
| webapp local storage
|}


'''Communication with Component Y'''  
'''Communication with Component Y'''  
Mixedpuppy
Confirmed users
169

edits

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

Navigation menu