|
|
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: |
| * → <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>
| |
| * → <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}}. | |