Ferreteria/v0.5/login: Difference between revisions
< Ferreteria | v0.5
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
* (TBD) - form widgets | * (TBD) - form widgets | ||
==Process== | ==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) note Account ID, (b) update WhenUsed | |||
*** Account bookkeeping: update WhenLogin | |||
*** Login object bookkeeping: (a) save Session and Account; (b) note success | |||
** Else (if not matched) | |||
*** Login object bookkeeping: (a) save Account; (b) note failure | |||
* Else (if not found) | |||
** Login object bookkeeping: (a) note failure | |||
===ReAuth=== | |||
* If browser has a Session cookie: | |||
** Search for matching Session | |||
** If found: | |||
** Else (no matching Session) | |||
* Else (no Session cookie) | |||
===Logout=== | |||
==Code== | |||
There are two major phases of a logged-in session: | There are two major phases of a logged-in session: | ||
* 1. right after the user has attempted a login: if login is 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. | * 1. right after the user has attempted a login: if login is 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. |
Revision as of 15:19, 23 March 2022
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) note Account ID, (b) update WhenUsed
- Account bookkeeping: update WhenLogin
- Login object bookkeeping: (a) save Session and Account; (b) note success
- Else (if not matched)
- Login object bookkeeping: (a) save Account; (b) note failure
- Else (if not found)
- Login object bookkeeping: (a) note failure
ReAuth
- If browser has a Session cookie:
- Search for matching Session
- If found:
- Else (no matching Session)
- Else (no Session cookie)
Logout
Code
There are two major phases of a logged-in session:
- 1. right after the user has attempted a login: if login is 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. when we need to check the user's session-cookie before we can know whether they're logged in or not (i.e. most of the time)
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>)
- Set the internal login status:
- Log the results (
$this->CreateEvent(...)
) - On success:
- update the applicable Session record (
<Session Storage Row>->UpdateForLogin($idAcct)
)
- update the applicable Session record (
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.