Ferreteria/v0.5/login

About

The login feature consists of several filesets:

• data (login) - core data and storage I/O classes
• dropin (dropins/login) - admin display I/O
• status (login/status.php) - login status class
• (TBD) - form widgets

Process

Login

This happens when the user submits a username and password.

• Search for username in the Accounts table.
• If found:
  • Check password match
  • If matched:
    • (login conditions satisfied for now -- though eventually we'll want to check account status in case it is suspended (not yet supported))
    • Find/create Session record for user's browser
    • Session bookkeeping: (a) save Account ID, (b) update WhenUsed
    • Account bookkeeping: update WhenLogin
    • Login object bookkeeping: (a) save Session and Account; (b) note success
    • Event log: successful login
  • Else (if not matched)
    • Login object bookkeeping: (a) save Account; (b) note failure
    • Event log: failed login, bad pw
• Else (if not found)
  • Login object bookkeeping: note login-failed
  • Event log: failed login, unknown user

ReAuth

• If browser has a Session cookie:
  • Search for Session matching the cookie
  • If found:
    • Session bookkeeping: update WhenUsed
    • Account bookkeeping: update WhenUsed
    • Login object bookkeeping: note session-logged-in
  • Else (no matching Session)
    • if Session ID matches but token is wrong:
      • Event log: token mismatch (possible hacking attempt)
    • Create new Session
    • Send correct Session cookie to browser
    • Login object bookkeeping: note not-logged-in
• Else (no Session cookie)
  • Search for Session matching the browser profile
  • If found:
    • Generate Session cookie and send it to browser
    • Login object bookkeeping: note not-logged-in

Logout

• Check login object: are we currently logged in?
• If yes:
  • Login object bookkeeping: note logged-out
  • Event log: user logged out
• Else (not logged in):
  • Event log: redundant logout

Code notes

Logged-in sessions come in two flavors -- login and reauth.

• 1. Login is right after the user has submitted user/pw creds. If successful, the user's browser is given a session-cookie to use and is then immediately redirected (to clear out the POST input, thus preventing accidental multiple logins) and we go to phase 2.
• 2. Reauth is when we need to check the user's session-cookie before we can know whether they're logged in or not. This represents the majority of logged-in sessions.

In-memory login state is stored in the static csLogin class (login/status.php).

writing login status

There are two ways the login status can be set: (a) actively logging in, (b) checking authenticity of a requested session

logging in

<Account Feature>->TryLogin($sUser,$sPass) : handle the logic for user login attempt; do necessary bookkeeping for result

• → <Account Storage Row>->AuthorizeLogin($sUser,$sPass) : lookup the given username, see if the password hash matches the stored hash
  • Set the internal login status: csLogin::SetAccountStatus(<results of search for login name>)
• Log the results ($this->CreateEvent(...))
• On success:
  • update the applicable Session record (<Session Storage Row>->UpdateForLogin($idAcct))

authenticating session

<Session Feature>->UserIsLoggedIn()

• → NativeRow()->UserIsLoggedIn()

reading login status

Example: see code in cMenuLink->FigureIfAuthorized() in tree/items/MenuLink.php

• This is called once per object from ftRequiresPermit->OnRunCalculations() in tree/items/traits.php.