Ferreteria/v0.5/login: Difference between revisions
< Ferreteria | v0.5
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
* 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. | ||
* 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) | * 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 <code>csLogin</code> class ({{l/ferreteria/code|login/status.php}}). | |||
===writing login status=== | ===writing login status=== | ||
There are two ways the login status can be set: (a) actively logging in, (b) checking authenticity of a requested session | There are two ways the login status can be set: (a) actively logging in, (b) checking authenticity of a requested session | ||
====logging in==== | ====logging in==== | ||
{{arg|Account Feature}}<code>->TryLogin($sUser,$sPass)</code> : handle the logic for user login attempt; do necessary bookkeeping for result | |||
* → | * → {{arg|Account Storage Row}}<code>->AuthorizeLogin($sUser,$sPass)</code> : lookup the given username, see if the password hash matches the stored hash | ||
* | * Log the results (<code>$this->CreateEvent(...)</code>) | ||
*** | * On success: | ||
** update the applicable Session record ({{arg|Session Storage Row}}<code>->UpdateForLogin($idAcct)</code>) | |||
====authenticating session==== | ====authenticating session==== | ||
{{arg|Session Feature}}<code>->UserIsLoggedIn()</code> | |||
* → <code>NativeRow()->UserIsLoggedIn()</code> | * → <code>NativeRow()->UserIsLoggedIn()</code> | ||
Revision as of 12:42, 19 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
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 - Log the results (
$this->CreateEvent(...)) - On success:
- update the applicable Session record (<Session Storage Row>
->UpdateForLogin($idAcct))
- update the applicable Session record (<Session Storage Row>
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.