Labs/Weave/Identity/Account Manager/Common Site Patterns
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
Many websites handle users such as showing logged-in status and requesting credentials. This document provides examples of various common site patterns in use today. Each example describes the page behavior and how Account Manager fits in for that particular set of attributes.
Contents
Site Pattern Examples
Each section below describes what the page does and how accounts are handled. Certain attributes are highlighted for easier comparison to behaviors on other sites.
There is also a description of how the Account Management APIs fit in at a high level as well as some technical details of what values are transmitted.
Bugzilla Home Page
URL: https://bugzilla.mozilla.org/
Description: A simple log-in form on a page that returns to the page when logged in.
| Account Status | Logged Out |
|---|---|
| Request Credentials | In Page |
| Domain Organization | Single Domain |
| Login Success | Show Original |
The server responds with X-Account-Management-Status: none, so the browser allows the user to click one button in the chrome UI to log into the account. This action will make a request according to the AMCD and set the appropriate cookies. Now the page will be refreshed and the server responds with the logged-in content.
The user no longer needs to scan the page to figure out if s/he is logged in, and if not, does not need to find the fields to input credentials.
Google Home Page
Description: A linked log-in form located on a separate page that redirects back to the original page.
| Account Status | Logged Out |
|---|---|
| Request Credentials | Linked Page |
| Domain Organization | Single Domain |
| Login Success | Show Original |
Just like Request Credentials In Page, the server responds with X-Account-Management-Status: none, and the user can use the chrome UI to log in.
Instead of searching for the login link and waiting for the page to load and fill out forms, the user can just look and click in one place to log in immediately.
Flickr Home Page
Description: A linked log-in form hosted on a domain that handles logins for multiple sites.
| Account Status | Logged Out |
|---|---|
| Request Credentials | Linked Page |
| Domain Organization | Multiple Domains |
| Login Success | Show Original |
Instead of hosting the AMCD on the same server, the /.well-known/host-meta entry would reference a remote AMCD, e.g. https://login.yahoo.com/amcd. Like any other AMCD, it informs the browser about how log in and find account status. Alternatively, the page could respond with a header to specify the AMCD, e.g., X-Account-Management: https://login.yahoo.com/amcd.
Following the instructions in the AMCD, the browser can find out that the user is not logged in, equivalent of a X-Account-Management-Status: none. The main difference is that Flickr pages don't need to send these HTTP headers and defer Account Management compatibility to Yahoo with the /.well-known/host-meta entry.
If a user visits Flickr for the first time, but uses a Yahoo account, s/he will see that s/he can log in (and not need to create a new account). This is because credentials are stored per-AMCD.
Note: It is up to Flickr and Yahoo to communicate to each other that the user is actually logged in. The browser UI can indicate the user is now logged in (to Yahoo) from Flickr, but the pages served by Flickr need to be of the appropriate content.
TODO:? How does flickr and yahoo know the same user is talking to them?
Gmail Inbox
URL: https://mail.google.com/mail/#inbox
Description: Accessing an auth.-required page results in redirecting the user to a log-in page on a different domain. After logging in, the user is redirected to the original requested page.
| Account Status | Force Connect |
|---|---|
| Request Credentials | Redirected Page |
| Domain Organization | Multiple Domains |
| Login Success | Show Original |
In addition to the 302 response to redirect to the log-in page, the server responds with X-Account-Management-Status: connect, so browsers that support Account Management may cancel the redirect and perform the log-in behavior. Then on success, the original request, view Gmail Inbox, is reissued.
To the user, it seems like the original URL request for the Inbox (perhaps accessed from a bookmark) took slightly longer than accessing the URL if already logged in. There's the extra log-in activity done in the background, but the user would no longer bounce from page to page to log in.
Just like the Flickr example above with Multiple Domains, Gmail can point to www.google.com's AMCD to reuse accounts. In this case, Gmail needs to support a little bit more of Account Management by overriding the Account Status with connect.
Amazon.com Your Orders
URL: https://www.amazon.com/gp/css/history/orders/view.html
Description: Accessing an auth.-required page results in log-in fields replacing the logged-in page contents.
| Account Status | Force Connect |
|---|---|
| Request Credentials | In Page |
| Domain Organization | Single Domain |
| Login Success | Show Original |
This looks like the simple Bugzilla Home Page case with a log-in form, except the server adds the header X-Account-Management-Status: connect to the 200 response. The browser may prevent the page and its log-in fields from being rendered and instead connect in the background, and on success, reissue the original request for the Your Orders page.
Site Pattern Attributes
Lots of old stuff from before reordering...
|
|
THIS PAGE IS A WORKING DRAFT |
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
Account Status
Logged In
Returning Visit
The user is identified to the server with a cookie and does not need to re-authenticate.
Logged Out
Requesting Credentials
Pages have a number of ways to request credentials. Some might have fields on the same page while others defer to another page.
The page that actually asks for credential information may be on the same page or on another page.
Same Page
A log-in form is provided that accepts credentials and returns to the same page.
Other Page
A link is provided that leads to a page (potentially on another site) requesting credentials.
Server Organization
A single server can handle everything including serving pages and sign-in, but multiple content servers can rely on one server for auth.
Same Server
Auth. Server
Login Success Behavior
After successfully logging in, the user can end up on a number of pages.
Original Page
Landing Page
Page Access Control
Some pages on a site may or may not require an account before accessing content. User-specific views of a site, e.g., personal messages or account information, require an account to show information. Accessing a page without first authenticating results in some server responses.
External Auth. Redirect (30x)
The browser is redirected with a 302, to a log-in page (of a different URL) where the user enters credentials and then may get redirected to the original page.
With Account Manager, the server would respond with X-Account-Management-Status: connect on the 302 (so other browsers get the normal page). The target of the redirect is not actually accessed and instead Account Manager attempts to connect. If successful, the original request, which 302ed, is retried.
Internal Auth. Redirect (200)
The server internally "redirects" to a log-in page by responding with a 200 where the page contents displays log-in fields instead of normal content. Submitting credentials ends up at the original requested page now with content.
With Account Manager, the server would respond with X-Account-Management-Status: connect on the 200. The contents of the page with the login fields would not actually get rendered and instead Account Manager attempts to connect. If successful, the original request is reissued.
Auth. Not Required (200)
Some pages on a site are accessible whether or not the user is logged in. A common example would be the home page of a site. These pages may be augmented if a user is logged in or may not change even after logging in.
See sections about Account Status and Signing In.
Access Forbidden (403)
Example: Accessing a page for which you don't have permission
The user ends up on a 403 page without further action that can be immediately done in the browser.
With Account Manager, the browser wouldn't automatically do anything as this is an explicit end-point. The server would respond with X-Account-Management-Status: active to indicate that the user is logged-in, so the user could use the in-chrome UI to switch to another account that might have access.
Access Denied (401)
Example: Credentials failed
The user ends up on a 401 page without further actions.
With Account Manager, the server would respond with X-Account-Management-Status: none to allow the user to connect, potentially with a different account.
