Ferreteria/v0.5/login: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
No edit summary
(moved phases into subpages)
Line 1: Line 1:
==About==
==About==
The login feature consists of several filesets:
The login feature handles user/session authentication. It consists of three main phases:
* '''{{l/sub|data}}''' ({{l/ferreteria/code|login}}) - core data and storage I/O classes
* [[/submit]]: checking user's submitted credentials
* '''{{l/sub|dropin}}''' ({{l/ferreteria/code|dropins/login}}) - admin display I/O
* [[/session]]: checking Session cookie
* '''{{l/sub|status}}''' ({{l/ferreteria/code|login/status.php}}) - login status class
* [[/logout]]: handling of user logout
* (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 <code>csLogin</code> class ({{l/ferreteria/code|login/status.php}}).
Code files/filesets involved include:
===writing login status===
* {{l/ferreteria/code|login}} - core data and storage I/O classes -- see {{l/sub|data}}
There are two ways the login status can be set: (a) actively logging in, (b) checking authenticity of a requested session
* {{l/ferreteria/code|dropins/login}} - admin display I/O
====logging in====
* {{l/ferreteria/code|login/status.php}} - login status class
<code>{{arg|Account Feature}}->TryLogin($sUser,$sPass)</code> : handle the logic for user login attempt; do necessary bookkeeping for result
* form widgets:
* &rarr; <code>{{arg|Account Storage Row}}->AuthorizeLogin($sUser,$sPass)</code> : lookup the given username, see if the password hash matches the stored hash
** {{l/ferreteria/code|tree/page/LoginWidget.php}}
** Set the internal login status: <code>csLogin::SetAccountStatus({{arg|results of search for login name}})</code>
*** {{l/ferreteria/code|tree/page/LoginWidget_block.php}}
* Log the results (<code>$this->CreateEvent(...)</code>)
*** {{l/ferreteria/code|tree/page/LoginWidget_inline.php}}
* On success:
** {{l/ferreteria/code|tree/page/traits-login.php}}
** update the applicable Session record (<code>{{arg|Session Storage Row}}->UpdateForLogin($idAcct)</code>)
 
====authenticating session====
<code>{{arg|Session Feature}}->UserIsLoggedIn()</code>
* &rarr; <code>NativeRow()->UserIsLoggedIn()</code>
 
===reading login status===
 
 
Example: see code in <code>cMenuLink->FigureIfAuthorized()</code> in {{l/ferreteria/code|tree/items/MenuLink.php}}
* This is called once per object from <code>ftRequiresPermit->OnRunCalculations()</code> in {{l/ferreteria/code|tree/items/traits.php}}.

Revision as of 15:38, 24 March 2022

About

The login feature handles user/session authentication. It consists of three main phases:

  • /submit: checking user's submitted credentials
  • /session: checking Session cookie
  • /logout: handling of user logout

Code files/filesets involved include: