User:Clouserw/AMO:Sessions

	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.

:80 vs. :443

No longer valid! Due to concerns with MITM attacks and mixing SSL and non-SSL we've decided to stay 100% on SSL. I'll leave this page up for reference.

Generic login function does something similar to:

• expires existing session if it exists
• secure cookie (we'll call it session cookie) is set:
  • Expires at end of session unless "remember me" was checked, then it expires in +X weeks.
  • https-only, includes:
    • session ID: uniquely identify session
    • hash(secretFromServer + sessionId + ??): This is a short hash (md5 is fine) that will tell us if the session ID has been tampered with
• insecure cookie (we'll call it token cookie) is set:
  • Expires at end of session unless "remember me" was checked, then it expires in +X weeks.
  • includes:
    • a token: hash(random) is fine. This is stored alongside the secure session ID in the db
    • a hash: hash(secretFromServer + token + ??): hash to check tampering

• We'll have a function to verify cookies using the hashes whenever anything secure is being accessed
• When changing a password, all sessions/cookies are removed and the user changing the password is reissued another one
• Insecure pages can key off the token cookie - if it exists, we can assume the user is logged in.

Use cases

User logs in from the front page:

• [SSL] Goes to SSL page for logging in
• user is forwarded back to the http front page. The front page now has generic "logged in" content like a link to "my add-ons" and such just because the token cookie exists.

User wants to edit a full page of content:

• [SSL] If cookies don't exist or can't be verified they are sent to SSL page to log in
• User is forwarded back to edit page (over either http or https, depending on implementation)
• [SSL] edit page knows it's content needs to be SSL and verifies user is using https or forwards to https

User wants to adjust content on an insecure page

• This is like an [edit] button next to an add-on description
• User makes adjustment
• [SSL] AJAX request is sent over SSL to API. Success/fail response is returned and user is shown appropriate message.
• If user isn't logged in, they won't see [edit] buttons. If a user somehow submits a request via ajax without a valid session it will return failure.

User wants to install an add-on:

• Doesn't matter if user is on https or not, logged in or not
• User clicks "install"
• [SSL] JS does an ajax request over SSL for the file hash, passing:
  • URL of file it wants the hash for
• file (over plain text) and hash are passed to browser's add-on installer

User wants to download an add-on:

• subtle difference, but we're assuming there is no installTrigger() fired
• this is no different than going directly to the .xpi URL. There is no hash checking, and the user is forwarded to the mirror network.
• No SSL involved.

Additional Domains

versioncheck.addons.mozilla.org

• Will remain completely SSL

services.addons.mozilla.org

• Will act like addons.mozilla.org. It will know what parts of itself should be SSL and will redirect accordingly

static.addons.mozilla.org

• Will provide normal and SSL copies of itself, but won't do any redirection

Stuff that still needs addressing

• We want to show [edit] buttons on a user's add-on detail page, their profile page, etc.
• If a user manually goes to HTTPS, I think they should stay on it
• security team verification that the add-on installing process is appropriate