Overview
As part of integrating self service circulation terminals and FOLIO (edge-sip2), the requirement of a separate PIN field came up.
PIN authentication via SIP2 has already been implemented
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | SIP2-61 |
---|
|
, using the user password field. However, the user password field has been deemed unsuitable for various reasons. The idea here is to introduce and utilize a separate PIN field instead of the password field for SIP2 authentication.
...
Related Jira issues
Jira Legacy |
---|
server | System JiraJIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-1811 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-3040 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | SIP2-89 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | MODUSERS-254 |
---|
|
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | SIP2-61 |
---|
|
...
The comments on this page and a discussion of this topic in the tech leads meeting on (2021-06-23) have been in favor of putting the PIN related functionality into the mod-users module. PIN related functions should be provided as part of a separate interface and the data kept in a separate table, so that queries to a user record do not return PIN related information.
...
/patron-pin
POST - to initially set a PIN for a patron/user
DELETE - to delete a PIN record
/patron-pin/verify
POST - verify whether a PIN matches the one stored for a user
returns:
- 200 Ok, if supplied PIN matches the stored record
- 422 401Unprocessable UnauthorizedEntity, otherwise
Data thats beeing sent in POST requests could look like:
...
- To keep the consistency between the users table and the pin table
- it should not be possible to store a PIN for a non-existing userId
- also the PIN information should be removed once a user gets deleted
- PINs will not be created automatically
- Setting/updating of PINs will happen through:
- the library's discovery system (mod-patron)
- the user import process (mod-users-import)the UI by requesting a password reset link
The functionality for an email based PIN reset will be addressed later and should work similar to FOLIOs password reset mechanism.
...