Services/F1/Design

Outline of F1 Design

This design outline shows what we intend to have in place in the short term (early April 2011). It does not reflect the current state in all places as of March 30, 2011.

Each numbered circle will be described below, including type of data stored, type of data transmitted, and locations for further details.

Two important pages to review as well are:

• Services/F1/Server/Architecture (descriptions of server side architectures under consideration, both synchronous and asynchronous using MQ)
• Services/F1/Server/API (outline of the API endpoints in the F1 server)
• Web/Addon Post Message API is close to, but not the final API.

A general consideration is that, any F1 data stored in chrome is stored there for 'safety and durability' in between share operations. When a user initiates a share, any data stored in chrome that is specific to the service being used will be transferred to the api server, and thus on to the 3rd party service.

1. OAuth tokens are returned (contained in an account object) from the Python API Server after authorization of a service. These tokens will be stored in chrome, encrypted using the same encryption the password manager uses. This account object also contains personal profile information such as email addresses, account usernames, id's etc. This account object is returned to the Python API server for each API request. Contents of this object are described at Services/F1/Server/API.

2. A user profile is contained in the account object described above, however it could be stored separately. What will also be stored separately are the user contacts/friends retrieved from each service. These are stored in Portable Contacts format, and may contain personal information such as email addresses, account usernames and id's, etc., depending on the service and what they return. The contacts api is described in Services/F1/Server/API.

3. A javascript object is stored on each tab in the browser, if the user has opened the f1 panel on that tab. This object contains information gathered about the content in the tab (see #4) as well as any data the user may have entered into the panel prior to sharing. This object will also contain the results (e.g. error status) of the sharing process. Those results are returned from the Python API server (the send api described in Services/F1/Server/API). This object is only destroyed when the tab is closed.

4. The chrome component of F1 accesses information in the browser content that currently includes: url, title, site name, short url, image previews. This data is gathered from OpenGraph meta tags, title elements, other meta tags, etc. Some of this data is inserted into DOM to be displayed to the user in the show panel browser.

5. The chrome component posts messages to the share panel content. Data includes the user account object (including OAuth tokens), contacts gathered from the services, data gathered about the current tab (see #4). Some of these post messages may be in response to a post message received from the share panel content. It is assumed that the content will not store this data. It is assumed any or all this data may be sent onwards to the Python API server when a user shares. It is important to note that the URL to the Python API server is stored in the user preferences and may be overridden to point to any server.

6. The share panel content posts messages to chrome that includes user account details and contacts. It also uses post messages to request the share content for the current tab (#4), to retrieve generated thumbnails for the current tab content, to store preferences set by the user on the settings page, or to indicate to chrome the need for UI events (such as opening or closing the panel).

7. This is just a simple http request/response for static pages that create the share UI in the share panel. No state outside typical server session cookies is used here.

8. API requests come in two flavors, authorization requests to retrieve OAuth tokens for services, and API calls to retrieve contacts or send a share. Details are located in Services/F1/Server/API. The account object containing the oauth tokens is required as a part of the request for contacts and send. Some user profile data and possibly some data about the users contacts (e.g. for a direct message) may also be included.

9. The contacts API will return a set of contacts retrieved from each service. The send API will return success/failure information, often including the data as returned by the 3rd party oauth api.

10. The Python server will only store temporary state via session management that is required during the openid and oauth authorization. No state is stored for the contacts or send api calls. The temporary state is stored in membase.

11. The oauth workers (really a part of the python server for now) may send status information into Membase for use by the status service. This information is basically about the health of the 3rd party service (e.g. x failures in the past x minutes). I've separated them into their own box as they are in their own python module on github at mozilla/server-share-core.

12. Assume that any data sent to the api in #8 is also sent to the 3rd party. Likewise, any data returned will be returned to the client.

13. Membase is used for session storage related to openid/oauth authorization states. The TTL on this can be very short. It is also used to store generic information about the health of remote services, which is consumed by an NGINX process (e.g. used to decide whether to cut off requests from clients). (Tarek for further details)

14. The status plugin is a simple C based extension to NGINX to coordinate remote service health with NGINX. (Tarek for further details) This plugin looks for a header in the HTTP request that will contain the name of the service the api call is meant for. It then will check against the membase storage to see if the service is up or down. If it is down, it will return 503, if it is up, it will let the request pass through to the python api server.