Skip to content

Documentation
Documentation
Commit 3af7467f by Tom Laudeman
Options

Add new DBUser spec file, update requirements and spec to match actual code

parent 9757b688
Showing with 330 additions and 242 deletions
Requirements/DBUser API.md
...@@ -11,35 +11,72 @@ For background about users, please see: ...@@ -11,35 +11,72 @@ For background about users, please see:
### What data and features must be provided ### What data and features must be provided
- user must have a unique id, which we mint when creating the database record - user must have a unique id, which we mint when creating the user database record in the database. The id is
- user must be able to authenticate (log in), which is currently handled outside DBUser by OpenID. supplied by the database as a record id, which is a unique integer. User must have a unique username, which
- user must be authorized for specific system features, which relies on role(s). is some string; we currently use an email address for username
User id must be unique for all time, and thus, user ids may not be reused. We have a unique user id internal - support for data necessary to authenticate (log in), which is currently handled outside DBUser by
to the system, which is the row id from table appuser. We do not currently have (or need) a textual user id OpenID. This data includes an access token and expires time
such as "mst3k", although email address must be unique to our system and serves an identifier. For example:
"mst3k@example.com" should be unique for all time, but (in theory) could be reused with a new, unique system
use rid.
Accounts need an active flag. Deleted accounts might be kept inactive, as an easy way to prevent accidentally - support for user authorization for specific system features. This requirement relies on role(s).
creating an account with the same name at some future time.
The list of features are described in more detail in other requirements docs although we list them below with - create user, requries a username which we default to the email address string. We also expect that the email
roles. Requirements here will cover implementation of authorization, and of management of authorization. field will contain an email address. There was some discussion of multiple email addresses per user. That
has not been implemented.
- update user, all fields except the ID and username; ID must never be modified. Changing username will have
unpredictable consequences.
- delete or inactivate user
- create role
- add role to user
- remove role from user
- delete role (probably inadvisable, but we make it possible)
- allow multiple roles per user
- create session
- extend session expiration time
- add session to user
- remove session from user
- remove all sessions from user
User id must be unique for all time, and thus, user ids may not be reused. We have a numerical unique user id
internal to the system, which is the row id from table appuser. We added a textual username which
traditionally would be something such as "mst3k" or an email address. We default to using an email address as
username. Currently, email address in the email address field is not necessarily across our system, and
therefore is not a reliable identifier.
Accounts have an active flag. Deleted accounts might be kept in an inactive state in the database. It is
unclear what information in an inactive account is important historically. An inactive account would prevent
using that account's username due to username being unique in table appuser. User ID values cannot be
accidentally reused because the database creates them from a Postgres sequence.
Some features are described in more detail in other requirements docs although we list them below with
roles. Requirements here will cover data necessary to support implementation of authorization, and support
management of authorization.
Each user has account info: Each user has account info:
- id (not editable, database assigned record id) - id (not editable, database assigned integer record id)
- username, unique string, we currently use an email address string
- active (boolean) - active (boolean)
- first name - first name
- last name - last name
- full name - full name
- email which serves as a unique identifier in some special contexts - email, not unique
- user id which may be email, should probably be unique
- avatar - avatar
- avatar small - avatar small
- avatar large - avatar large
- password, stored encrypted - password, stored hashed
When logged in, a user has at least one "session", and the session has some associated data. We anticipate When logged in, a user has at least one "session", and the session has some associated data. We anticipate
that there could be multiple simultaneous sessions per user, and each session needs its own unique data. that there could be multiple simultaneous sessions per user, and each session needs its own unique data.
...@@ -51,16 +88,17 @@ Current session data includes: ...@@ -51,16 +88,17 @@ Current session data includes:
The REST API requires the same session data. REST API users will have the same Au/Az constraints The REST API requires the same session data. REST API users will have the same Au/Az constraints
The system has roles conceptually, extensively integrated throughout. Each user is granted one or more roles. The system has roles conceptually, extensively integrated throughout the DBUser API. Each user is granted one
Each user has one or more roles, as many as necessary. or more roles. Each user has one or more roles, as many as necessary.
### Roles ### Roles
The SNAC permission system is based entirely on roles (groups). SNAC is authorizing uses to run various The SNAC permission system is based entirely on roles (groups). SNAC is authorizing users to run various
functions. Ownership is a non-concept, but essentially the system ("root") owns all functions. In a situation functions. Ownership is a non-concept, but essentially the system owns all functions. In a situation like SNAC
like SNAC where there is a single owner, the concept of "owner" has no use in authorization. That leaves SNAC where there is a single owner, the concept of "owner" has no utility in authorization. The Linux concept of
with a role-only system. "other" doesn't apply to SNAC as "other" is only allowed to perform read-only actions such as search. That
leaves SNAC needing only a role system.
(Optional paragraph) Not having "files", there is no concept of "file has no privileges" for user, group, or (Optional paragraph) Not having "files", there is no concept of "file has no privileges" for user, group, or
other. An example of what SNAC does not have is the shared web server situation where user grants privileges other. An example of what SNAC does not have is the shared web server situation where user grants privileges
...@@ -70,7 +108,8 @@ user, no one in group user has any access. Actual access then is granted only to ...@@ -70,7 +108,8 @@ user, no one in group user has any access. Actual access then is granted only to
read-write-execute (rwx) for that directory. Apache runs as suexec for each user, and thus each user's CGI read-write-execute (rwx) for that directory. Apache runs as suexec for each user, and thus each user's CGI
scripts gain access to only that user's directory via the user privs. scripts gain access to only that user's directory via the user privs.
SNAC lacks this "subtractive" permission, and instead has only additive permissions. SNAC lacks the Linux "subtractive" permission which is sometimes used with groups permissions. Instead SNAC
has only additive permissions.
In a global sense, the cumulative collection of users and roles is complicated. However, that complexity is In a global sense, the cumulative collection of users and roles is complicated. However, that complexity is
essential (not accidental) and on a per-user or per-role basis, things are very manageable. When managing the essential (not accidental) and on a per-user or per-role basis, things are very manageable. When managing the
...@@ -78,20 +117,22 @@ system, imagine asking these typical, and manageable questions: ...@@ -78,20 +117,22 @@ system, imagine asking these typical, and manageable questions:
- List all users affiliated with California Digital Library (CDL). - List all users affiliated with California Digital Library (CDL).
- List all user affiliated with UC Irvine. - List all users affiliated with UC Irvine.
- List all users who can enroll new users for any affiliation
- List all users who can enroll new users. - List all users who can only enroll new users for NYPL
- List all users who can publish constellations. - List all users who can publish constellations.
- List all users who may run reports for their own affiliation. - List all users who may run reports for their own affiliation.
Below is an example. Anyone who can log in can get a dashboard, so there are no specific dashboard permissions Below is an example. Anyone who can log in can get a dashboard, so there are no specific dashboard permissions
(yet). The user id "public" and the role "researcher" may not make any sense. Everyone has role "Public HRT", (yet). The user id "public" and the role "research" may not make any sense. Conceptually, everyone has role
so there's no reason to restrict or authorize it. This table initially had a user id "public" with role "Public HRT", so there's no reason to restrict or authorize it. In actual implementation the "what is public"
"Public HRT", and every user also had the role "Public HRT", but that is simply redundant. When it comes to divide is simply any published record or read-only actition on published constellations. The table below
implementation, the authorization system will use some convention for testing role. The feature "Public HRT" initially had a user id "public" with role "Public HRT", and every user also had the role "Public HRT", but
can call a role test that always returns true. that was simply redundant.
The roles below are real, but do not imply any actual policy or any relation to persons living or dead. The roles below are real, but do not imply any actual policy or any relation to persons living or dead.
...@@ -102,64 +143,70 @@ Pulling a couple of random details from the table below, and wording them in Eng ...@@ -102,64 +143,70 @@ Pulling a couple of random details from the table below, and wording them in Eng
| user | description | roles | | user | description | roles |
|------------------+----------------+-------------------------------------------------------------------------------------------------| |------------------|----------------|-------------------------------------------------------------------------------------------------|
| Marley Turner | content expert | contribute, affiliation-none | | Marley Turner | content expert | contribute, affiliation-none |
| Remy Roberts | power editor | contribute, change-status-any, change owner, publish, affiliation-any | | Remy Roberts | power editor | contribute, change-status-any, change owner, publish, affiliation-any |
| Casey Miyazaki | editor CDL | contribute, change-status-own, publish, NACO approve, affiliation-cdl, reporter-own-affiliation | | Casey Miyazaki | editor CDL | contribute, change-status-own, publish, NACO approve, affiliation-cdl, report-own-affiliation |
| Jessie Coughlin | admin NYPL | affiliation-nypl, enroll-own-affiliation reporter-own-affiliation, role-assign-own | | Jessie Coughlin | admin NYPL | affiliation-nypl, enroll-own-affiliation report-own-affiliation, role-assign-own |
| Avery Valenzuela | super admin | enroll-any, reporter-any, role-assign-any | | Avery Valenzuela | super admin | enroll-any, report-any, role-assign-any |
Roles have a number of traits: Roles have a number of traits.
- Created by developers, and maintained by admins with role-granting privileges - Roles are additive, and all roles of a user define that user's authorized functions
- There is (ideally) a single privilege per role - Roles are created and maintained by admins and developers.
- Roles and privileges must be coordinated with work flows and application features - Some instance roles (such as affiliation) can be created by admins as needed.
- One role exists per institutional affiliation - Roles (ideally) have a single privilege per role. Roles are very granular.
- Every user has the implied role Public HRT - Roles and privileges must be coordinated with work flows and application features.
- One role exists per institutional affiliation.
- Every user has the conceptually role Public HRT, although no actual role exists for read-only access to published constellations
- Potentially, we can have roles for ad hoc groups (sub-institution, department, professional orgs, etc.) - Potentially, we can have roles for ad hoc groups (sub-institution, department, professional orgs, etc.)
- Roles can be deprecated, but re-purposing roles is inadvisable from a security standpoint - Roles can be deprecated, but re-purposing roles is inadvisable from a security standpoint.
- Need explicit, on-going policy guidance - Roles need explicit, on-going policy guidance.
Every account will have the "Public HRT" role which has the same privileges as the general public, but with a The minimal role "Research" grants privileges for search history, and certain research reports. Members of
TBD set of basic privileges including: search history, certain researcher reports. An account is not necessary the public are mostly identical to Researchers. The primary feature gained by having an account is a
to use SNAC. Members of the public are mostly identical to Researchers. The primary feature gained by having persistent dashboard. As already noted, "Public HRT" not an actual role, but instead is conceptual.
an account is a persistent dashboard.
(Comment: I just noticed that roles are mostly verbs: research, contribute, delete, propose, approve, block,
embargo, enrole, assign. It seems like a nice idea to enshrine this as a convention. We would have to change
| Role | Role Description | "administrator" to "administer", and we need to come up with a verbs for the remaining roles, especially
|------------------------------+-----------------------------------------------------------------------------| "affiliation".)
| Public HRT | No account, but may use HRT public interfaces to SNAC |
| Researcher | (Same as Public HRT?) Use discovery interface and dashboard, has an account |
| Contribute | Create and edit constellations but cannot publish (contributor) | | Role | Role Description |
| Publish | Approve constellation publication (editor) | |------------------------------+----------------------------------------------------------------------------|
| Change status any | Change status, removing locks, and so on, any affiliation | | Research | Use discovery interface and dashboard, has an account |
| Change owner any | Change constellation user, changing which user has a lock, any affiliation | | Contribute | Create and edit constellations but cannot publish (contributor) |
| Change status own | Change status, removing locks, and so on, own affiliation only | | Publish | Approve constellation publication, change status to "published" (editor) |
| Change owner own | Change constellation user, changing user lock, own affiliation only | | Change status any | Change any status, removing locks, and so on, any affiliation |
| Delete/embargo | Delete or embargo constellations (editor) | | Change owner any | Change constellation user, changing which user has a lock, any affiliation |
| Propose delete/embargo | Propose delete or embargo | | Change status own | Change any status, removing locks, and so on, own affiliation only |
| Ontology propose | Propose headings in ontologies, but cannot approve headings | | Change owner own | Change constellation user, changing user lock, own affiliation only |
| Ontology approve | Approve ontology headings (editor) | | Delete/embargo | Delete or embargo constellations (editor) |
| Propose NACO | Create(?) NACO contributions, but not push(?) to NACO | | Propose delete/embargo | Propose delete or embargo |
| NACO approve/finalize/submit | Approve NACO contributions (editor) | | Ontology propose | Propose headings in ontologies, but cannot approve headings |
| Enroll | Enroll new SNAC participants, create new users | | Ontology approve | Approve ontology headings (editor) |
| Role assign own institution | Assign new roles for own-institution users | | Propose NACO | Create(?) NACO contributions, but not push(?) to NACO |
| Role assign any institution | Assign new roles for any institution users | | Approve NACO | Approve, finalize, submit NACO contributions (editor) |
| System administrator | Maintains server hardware and operating systems | | Enroll | Enroll new SNAC participants, create new users |
| Developer | Writes the SNAC application, a programmer | | Role assign own institution | Assign new roles for own-institution users |
| Web administrator | (duplicate? historical?) May perform admin tasks via the web interface | | Role assign any institution | Assign new roles for any institution users |
| Database administrator | Create and maintain the SQL database | | System administrator | Maintains server hardware and operating systems |
| Block upload | Do bulk uploads of EAC-CPF, finding aids, etc. | | Developer | Writes the SNAC application, a programmer |
| Reporter own | Run own-institutional reports | | Web administrator | (duplicate? historical?) May perform admin tasks via the web interface |
| Reporter any | Run any report, super reporter | | Database administrator (DBA) | Create and maintain the SQL database |
| Affiliation X | Affiliated with institution X. | | Block upload | Do bulk uploads of EAC-CPF, finding aids, etc. |
| Affiliation any | Affiliated with all institutions, a super role (discuss?) | | Report own | Run own-institutional reports |
| Report any | Run any report, super reporter |
| Report admin | Run special administrative reports |
More example user types, with their role(s) and description. | Affiliation X | Affiliated with institution X. |
| Affiliation any | Affiliated with all institutions, a super role (discuss?) |
Example user types, with their role(s) and description.
| User type | Role(s) | User Description | | User type | Role(s) | User Description |
...@@ -167,176 +214,30 @@ More example user types, with their role(s) and description. ...@@ -167,176 +214,30 @@ More example user types, with their role(s) and description.
| Sysadmin | System administrator | Maintain server, backups, etc. | | Sysadmin | System administrator | Maintain server, backups, etc. |
| Database Administrator | DBA | Schema maintenance, data dumps, etc. | | Database Administrator | DBA | Schema maintenance, data dumps, etc. |
| Software engineer | Developer + DBA | Coding, testing, QA, release management, data loading, etc. | | Software engineer | Developer + DBA | Coding, testing, QA, release management, data loading, etc. |
| Manager | Enroll + Role assign + Inst. Reporter | SNAC accounts: create, manage, assign roles, run reports | | Manager | Enroll + Role assign own + Report own | SNAC accounts: create, manage, assign roles, run reports |
| Peer vetting | Enroll | Approve moderators, reviewers, content experts | | Peer vetting | Enroll | Approve moderators, reviewers, content experts |
| Moderator | Editor-publish | Approve maintenance changes, posting those changes | | Moderator | Publish | Approve maintenance changes, posting those changes |
| Reviewer/editor | Contributor + Editor-publish | Maintainer privileges, interacts with moderators | | Reviewer/editor | Contribute + publish | Maintainer privileges, interacts with moderators |
| Content expert | Contributor | Domain expert, may have zero institutional roles | | Content expert | Contribute | Domain expert, may have zero institutional roles |
| Documentary editor | Contributor | (Any distinguishing roles?) | | Documentary editor | Contribute | (Any distinguishing roles?) |
| Maintenance | Contributor, constellation | May be older terminology for "contributor" | | Maintenance | Contribute, constellation | May be older terminology for "contribute" |
| Researcher | Researcher | Use the discovery interface and history dashboard | | Research | Research | Use the discovery interface and history dashboard |
| Archival description donor | Block upload | May do bulk uploads of EAC-CPF, finding aids, etc. | | Archival description donor | Block upload | May do bulk uploads of EAC-CPF, finding aids, etc. |
| Name authority manager | Name authority | (superseded by Editor-NACO?) | | Name authority manager | Name authority | (superseded by Editor-NACO?) |
| Institutional admins | Institutional reporter | May run own-institutional reports | | Institutional admins | Report own | May run own-institutional reports |
| Public | Public | No SNAC account, single session dashboard | | Public | n/a | No SNAC account, single session dashboard |
| Contributor | Contribute + Ontology propose | Creates/edit constellations, propose ontology headings | | Contributor | Contribute + Ontology propose | Creates/edit constellations, propose ontology headings |
| Author | Contribute + Publish + Propose Del/Emb+Propose NACO | A contributor, with additional privileges | | Author | Contribute + Publish + Propose Del/Emb+Propose NACO | Contribute, with additional privileges |
| Editor | Contribute + Publish + Delete/embargo + NACO | Review constellations, approve and publish | | Editor | Contribute + Publish + Delete/embargo + NACO | Review constellations, approve and publish |
| Author-NACO | Create provisional NACO | Creates NACO entries, sends to editor for submission | | Author-NACO | Propose NACO | Creates NACO entries, sends to editor for submission |
| Administrator | Author + editor + enroll + assign | Everything, only own institution | | Administrator | Contributor roles + Editor roles + enroll + assign | Everything, only own institution |
| Administrator-super | Administrator + any institution | Admin plus assign roles for any user of any institution | | Administrator-super | Administrator roles + any institution | Admin plus assign roles for any user of any institution |
### API
Most of the API depends on a User object. That object must at least contain an email address. When creating,
saving, or updating a user, all available fields are written to the database except id (aka appUserID). The ID
is generated from the database.
createUser() creates a new id, overwriting any existing id.
saveUser() requires a valid id in order to update. The ID is not changed.
readUser() requires a valid id. The ID is not changed.
A user object has only a single session. There may be several active sessions per account. We assume that each
HTTP request will include unique session, keeping all concurrent sessions separate.
Role management works.
---
`checkSessionActive(snac\data\User $user)`
Check that a session is active (not expired) for $user. Time is assumed to be "now". Return a $user with valid
appUserID upon success, or false on failure. Adds the user to the db if the user does not already
exist. Creates a session if a session does not already exist.
If a session exists, that session expires is checked against now() as UTC. If the session has expired, then
the session is deleted, and the $user token is cleared by setting 'access_token' to '' and expires to zero.
The user is created based on email being unique. Any existing userID inside $user is ignored, then
overwritten.
The new user is not assigned a default role, but there is a function to add a default role if we need that.
---
`createUser(snac\data\User $user)`
Add a user record. Minimal requirements is a unique email. Return the new User object. The current
implementation has no concept of failure. Adds a default role if we have one. We do not currently have a
default role.
---
`saveUser(snac\data\User $user)`
Update a user record. Overwrite everthing else with values from the User object. Please contact the developers
before using this function.
---
`findUserID($email)`
Get the user id if you only know the email address. We assume the email addresses are unique. Returns integer appUserID or false.
---
`readUser($userID)`
Return a User object for the user id or email. Return false on failure. Fills in the role list in the User object.
---
`readUserByEmail($email)`
Return a User object based on email address. Return false on failure.
---
`disableUser(snac\data\User $user)`
Disable log in to this account. Update table appuser.active to false. Return true on success.
Proably has not been tested. The concept of inactive accounts is not well defined.
---
`roleList()`
List all system roles as a list of Role objects.
---
`addUserRole(snac\data\User $user, $newRole)`
Add a role to the User via table appuser_role_link. Return true on success. $newRole is a Role object.
---
`addDefaultRole($user)`
Add default roles to $user, if any default roles exist. Currently does nothing. If we had default roles, it
would change $user in place. Would return true on success, false otherwise.
---
`listUserRole($user)`
List all the roles a user currently has as an array of Role objects.
----
`checkRoleByLabel($user, $label)`
Check for role by label. Returns the role if user has it, else false;
----
`removeUserRole($user, $role)`
Remove a role from the User by deleting the role link from table appuser_role_link.
----
`createRole($label, $description)`
Create a new role with $label and $description. Return the role on success. Currently, it has no concept of
failure.
---
`checkPassword(snac\data\User $user, $passwd)`
Check $passwd matches the password stored for snac\data\User. Return true on success.
---
`addSession(snac\data\User $user)`
Add a new session token $user->getToken()['access_token'] with expiration time $user->getToken()['expires']
for $user. Update the session if $accessToken exists.
---
`sessionExists($user)`
Find out if a session exists and if that session is associated with $user, and has not expired.
---
`removeSession($user)`
Remove a session. Assume that tokens are unique, which is important. Delete all sessions with the token ### API
$user->getToken()['access_token'] matter what user has that token.
---- See the specifications for the API functions.
`clearAllSessions(snac\data\User $user)`
Delete all session records for $user. [User Management API Specifications](Specifications/DBUser API.md)
----
Specifications/DBUser API.md 0 → 100644
### Introduction
Most of the API depends on a User object which contains a list of Role object. Before being written to the
database, a User must at least contain an username which we are defaulting to the email address string. After
being written to the database, a user must contain the userid (aka appUserID, aka id) and username. When
creating, saving, or updating a user, all available fields are written to the database except id (aka
appUserID) and username. The ID is generated from the database, and the username was supplied when the user
was first created. We assume that neither will ever change.
If there is an ID present in a User prior to the user being created, that ID will be overwritten. This might
occur where fields from a User come from an outside system with its own concept of user id.
createUser() creates a new id, overwriting any existing id in the User object
saveUser() requires a valid id in order to update. The ID is not changed.
readUser() requires a valid id. The ID is not changed.
A User object has only a single session. There may be several active sessions per account. We assume that each
HTTP request will include unique session, thus keeping all concurrent sessions separate.
### API
---
`checkSessionActive($user)`
Don't use this. Instead use granualar functions such as: sessionExists(), sessionActive(), addSession(),
sessionExtend(), readUser(), and createUser().
This does multiple actions including check that a session is active (not expired) for $user. Time is assumed
to be "now" UTC in seconds since the epoch. Return a $user with valid appUserID upon success, or false on
failure. Adds the user to the db if the user does not already exist. Creates a session with included token and
expires if a session does not already exist.
If a session exists, that session expiration time is checked against now() as UTC. If the session has expired,
then the session is deleted, and the User token is cleared by setting 'access_token' to '' and expires to
zero.
The User is created based on email being unique. Any existing userID inside $user is ignored, then
overwritten with the database supplied value which is an integer.
The new user is not assigned a default role, but there is a function to add a default role if we need that.
---
`createUser($user)`
Add a user record. Minimal requirements is a unique email. Return the new User object. The current
implementation has no concept of failure. Adds a default role if we have one. We do not currently have a
default role.
---
`saveUser($user)`
Update a user record. Overwrite everthing except user id with values from the User object. Please contact the developers
before using this function because there is no sanity checking in the function. This function is currently
unused and while it seems reasonable to have this function, it may be removed.
---
`findUserID($email)`
Get the user id if you only know the email address. We assume the email addresses are unique. Returns integer appUserID or false.
This is a nice low level function, but you probably want the high level readUserByEmail() which returns a User object.
---
`readUser($userID)`
Return a User object for the user id or email. Return false on failure. Fills in the role list in the User
object. This is a nice low level function, but you probably want readUserByEmail() which returns a User object.
---
`readUserByEmail($email)`
Return a User object based on email address. Return false on failure.
---
`disableUser($user)`
Disable this account. Definition of "disable" is evolving. Update table appuser.active to false. Return true on success.
Proably has not been tested. The concept of inactive accounts is not well defined.
---
`roleList()`
List all system roles as a list of Role objects.
---
`addUserRole($user, $newRole)`
Add a role to the User via table appuser_role_link. Return true on success. $newRole is a Role object, and you
probably want to call roleList() to get a list of available roles.
---
`addDefaultRole($user)`
Add default roles to $user, if any default roles exist. Currently does nothing. If we had default roles, it
would change $user in place. Would return true on success, false otherwise.
---
`listUserRole($user)`
List all the roles a user currently has as an array of Role objects.
----
`checkRoleByLabel($user, $label)`
Check a User object for role by label. Returns the role if user has it, else false;
----
`removeUserRole($user, $role)`
Remove a role from the User by deleting the role link from table appuser_role_link. Returns true.
The User object is modified in place, getting the updated list of roles.
----
`createRole($label, $description)`
Create a new role with $label and $description. Return the role on success.
---
`checkPassword($user, $passwd)`
Check $passwd matches the password stored for User. Return true on success.
Not used with OpenID, and not tested, but it is very simple.
---
`addSession($user)`
Add a new session to the database for the token $user->getToken()['access_token'] with expiration time
$user->getToken()['expires'] for $user. Update the session if $accessToken exists.
---
`sessionExists($user)`
Find out if a session exists for this User. Expiration time is ignored, so this is only answers "Does the session exist?"
---
`removeSession($user)`
Remove a session. Assume that tokens are unique, which is important. Delete all sessions with the token
$user->getToken()['access_token'] matter what user has that token.
----
`clearAllSessions($user)`
Delete all session records for $user.
---
`writePassword($user, $passwd)`
Write a hashed password to the database for User. The password itself it not part of the User object, so we
use some additional functions to manage passwords. This is not used during OpenID authentication.
----
`getSQL()`
Used only for testing. Returns the SQL object so that sql functions can be called directly.
---
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment