Summary: | Allow empty password fields in Patron Info requests | ||
---|---|---|---|
Product: | Koha | Reporter: | Colin Campbell <colin.campbell> |
Component: | SIP2 | Assignee: | Colin Campbell <colin.campbell> |
Status: | CLOSED FIXED | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | minor | ||
Priority: | P5 - low | CC: | colin.campbell, fridolin.somers, m.de.rooy, mtj, mtompset |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16610 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27600 |
||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: |
Some SIP devices expect an empty password field in a patron info request to be accepted as OK by the server. Since patch for bug 16610 was applied this is not the case. This reinstates the old behaviour for sip logins with the parameter allow_empty_passwords="1"
|
Version(s) released in: | |
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 18943, 23722 | ||
Attachments: |
Patch enabling the option
Bug 18755 Allow empty passwords in Patron Info to return OK Bug 18755: Allow empty passwords in Patron Info to return OK |
Description
Colin Campbell
2017-06-08 11:27:22 UTC
Created attachment 64101 [details] [review] Patch enabling the option To test send a patron info request with the patron password field (AD) containing no characters. Default returns CQ = N and 'Invalid password' in the screen message. Alter config file to add allow_empty_passwords="1" to the appropriate login parameters in accounts. Restart the sipserver to reread the config and repeat the request CQ is now returned as "Y" and the screen message does not report the password as invalid I figured the test added should fail under master, so: git bz apply 18755 git checkout origin/master -- C4/SIP/Sip/MsgType.pm prove t/db_dependent/SIP/Message.t -- fails as expected git reset --hard origin/master git bz apply 18755 prove t/db_dependent/SIP/Message.t -- passes as expected. This change is fully tested by the test that is added, so I'm going to sign off. Created attachment 64762 [details] [review] Bug 18755 Allow empty passwords in Patron Info to return OK With this patch a parameter 'allow_empty_passwords="1" can be added to a login in the SIP configuration file to allow the behaviour as was normal before the patch for bug 16610 was applied. Some sip clients rely on this behaviour sending an empty password field when they wish to validate to user but do not have the password. If a password is supplied it will be validated A test has been added to Message.t to confirm this behaviour Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Colin: What about Patron Status now? If you provide no AD field, Patron Status responds with a CQN (without Invalid password). Should it return a CQ? Same for empty AD; receive CQN. Should the new option change behavior here? Note: Patron Info without AD does not return a CQ. (Should it?) And an empty AD with allow_e_p returns a CQY. (In reply to Marcel de Rooy from comment #4) > Colin: What about Patron Status now? > > If you provide no AD field, Patron Status responds with a CQN (without > Invalid > password). Should it return a CQ? > Same for empty AD; receive CQN. Should the new option change behavior here? > > Note: > Patron Info without AD does not return a CQ. (Should it?) > And an empty AD with allow_e_p returns a CQY. Patron status is a bit odd the CQ is like patron info in being an optional field, but unlike patron info the AD password field is a required field so I assume that a missing AD should provoke an invalid password in return. basically the behaviour has remained unchanged. In practice I cant recall seeing any kind of unit that uses patron status, I think when sip 2 was released patron info effectively superceded it. So I think we should leave functionality as is, just in case anything relies on the current behaviour. ( I tested on a very old sip software before any of the patches affecting patron info to confirm that behaviour hadnt been inadvertantly changed by other patches) Created attachment 64797 [details] [review] Bug 18755: Allow empty passwords in Patron Info to return OK With this patch a parameter 'allow_empty_passwords="1" can be added to a login in the SIP configuration file to allow the behaviour as was normal before the patch for bug 16610 was applied. Some sip clients rely on this behaviour sending an empty password field when they wish to validate to user but do not have the password. If a password is supplied it will be validated A test has been added to Message.t to confirm this behaviour Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> (In reply to Colin Campbell from comment #5) > (In reply to Marcel de Rooy from comment #4) > Patron status is a bit odd the CQ is like patron info in being an optional > field, but unlike patron info the AD password field is a required field so I > assume that a missing AD should provoke an invalid password in return. > basically the behaviour has remained unchanged. In practice I cant recall > seeing any kind of unit that uses patron status, I think when sip 2 was > released patron info effectively superceded it. So I think we should leave > functionality as is, just in case anything relies on the current behaviour. > ( I tested on a very old sip software before any of the patches affecting > patron info to confirm that behaviour hadnt been inadvertantly changed by > other patches) Clear enough. Thanks. > With this patch a parameter 'allow_empty_passwords="1" can be added...
Can we document these kinds of parameters somewhere? Maybe in the example file? I am worried that these kind of features will remain mostly unknown if there are not more clues.
(In reply to Katrin Fischer from comment #8) > > With this patch a parameter 'allow_empty_passwords="1" can be added... > > Can we document these kinds of parameters somewhere? Maybe in the example > file? I am worried that these kind of features will remain mostly unknown if > there are not more clues. I wonder if we need to rethink the way SIP configuration is held. I'm not sure that adding options to an xml file is very accessible to many users. I agree, but that's probably a bigger issue. I am not sure how granular it is, but I think possibly it should be as granular as per 'sip2 using unit'? Having a commented example file might be quicker to achieve for now and helpful for moving things later. Pushed to master for 17.11, thanks to everybody involved! Pushed to 17.05.x, will be in 17.05.02 I've filed bug 18943 about the missing documentation. This patch has been pushed to 16.11.x and will be in 16.11.10. Pushed to 16.05.x, for 16.05.15 release |