Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keySIP2-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
serverSystem JiraJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-1811

Jira Legacy
serverSystem JiraJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-3040

Jira Legacy
serverSystem JiraJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keySIP2-89

Jira Legacy
serverSystem JiraJIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODUSERS-254

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keySIP2-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.

...