from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search


  • request session: the time between the initial request for a URL and when the code finishes executing
  • browser session (user_session): a way to identify whether we're talking to a given browser (client) on a given machine; uses cookie
  • browser identity (user_client): a given browser (client) at a given address, hopefully on a given machine, as identified by:
    • cookie
    • browser fingerprint: identifying information always presented by the browser:


This is how it should work:

browser session tracking

  • At the start of each request session:
    • get browser fingerprint
    • get browser cookie, if any (which gives session ID and a token string)
    • look up stored browser session from ID in cookie
    • if session cookie's token does not match actual token for that session
      • generate new session (and log error - possible hack)
    • if browser fingerprint in session record does not match actual browser fingerprint
      • generate new session (and log change - probably just user changing IPs or getting browser upgrade)

To do: maybe we want to give the user the option to not be logged out when they change IPs or browsers? But logging in is really quick...

login process

"Being logged in" means that the record for the current session has a user ID (ID_Acct) set.

  • At the start of each request session, after the browser session has been set up:
  • If the browser session has a user ID (ID_Acct) set, then we're logged in; otherwise, we aren't.

For now, we're not treating a {login-request received when already logged in} as an error, though we might log it as an edge condition to investigate. Login requests are handled the same whether we are already logged in or not.

  • When user requests login (by sending username and password):
    • find username in users table (user_account)
    • if (hashed) password from user matches stored password (hash):
      • assign ID of found user to user_session.ID_Acct
      • display login-success message
    • ELSE if it doesn't:

Object Model

The main objects in play are the session and user. The app object also plays a role.

  • session object
    • tracks which user is known to be logged in (to that session)
    • verifies that the browser details (including secret-token) match the browser known to be attached to the session
  • user object
    • handles password-checking
    • connects to the access-control system (what is user allowed to do)
    • connects (eventually) to user-preferences and user-history information
  • app object
    • tracks which session is currently active
      • (which also tracks which user is currently active)