Bug 15124 - Allow SIP2 passwordless operation
Summary: Allow SIP2 passwordless operation
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low minor (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-04 12:47 UTC by Kyle M Hall
Modified: 2016-12-05 21:22 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 15124 - Tidy relevent code (12.29 KB, patch)
2015-11-04 14:00 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 15124 - Allow SIP2 passwordless operation (4.06 KB, patch)
2015-11-04 14:00 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2015-11-04 12:47:46 UTC
Some SIP self check machines allow the use of a "passwordless" mode where the patron does not need to enter a pin or password to use the SC. Koha cannot handle this situation. Koha will assume an empty password field is an invalid password unless the patron's password is NULL in the database.
Comment 1 Kyle M Hall 2015-11-04 14:00:39 UTC
Created attachment 44369 [details] [review]
Bug 15124 - Tidy relevent code
Comment 2 Kyle M Hall 2015-11-04 14:00:45 UTC
Created attachment 44370 [details] [review]
Bug 15124 - Allow SIP2 passwordless operation

Some SIP self check machines allow the use of a "passwordless" mode
where the patron does not need to enter a pin or password to use the SC.
Koha cannot handle this situation. Koha will assume an empty password
field is an invalid password unless the patron's password is NULL in the
database.
Comment 3 Katrin Fischer 2015-11-04 21:39:32 UTC
Hm, I am surprised by this as we have libraries operating self checks without a pin/password entry from the user.
Comment 4 Colin Campbell 2015-12-09 11:19:59 UTC
Katrin is right. A password is not present in a (e.g) checkout transaction. The password checking logic is in the machine itself, the server end does not have the concept of a user session (each request is dealt with irrespective of what preceeds it). Whether the machine requires the user to authenticate with a password is an option on some of these, they ignore the field rather than asking us to lie about its validity.
I'm a bit worried a that its not clear what the import of the code is and that the config file is being swamped by extra options.