Ferreteria/v0.4/login: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
No edit summary
m (3 revisions imported: moving this project here)
 
(No difference)

Latest revision as of 16:44, 22 May 2022

Terminology

  • request session: the time between the initial request for a URL and when the code finishes executing
  • browser session (Template:L/ferreteria/table): a way to identify whether we're talking to a given browser (client) on a given machine; uses cookie
  • browser identity (Template:L/ferreteria/table): 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:

Processes

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.

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)