Patron account can be retrieved without opt-in

Bug #1684988 reported by Jeff Davis on 2017-04-20
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned
2.12
Undecided
Unassigned

Bug Description

In the web client in Evergreen 2.12 (and presumably earlier versions), there is an opt-in check during patron barcode search, which prevents the patron record from being retrieved unless the patron is opted-in. However, there are other ways to retrieve the patron record without an opt-in check -- for example, via item circ history. The web client should enforce an opt-in check whenever the patron record is retrieved, not just via barcode search.

My first thought is to enforce an opt-in check/dialog whenever a route beginning with 'circ/patron/:id' is accessed, but I don't know Angular well enough yet to know if that's a good approach.

The XUL client has the same issue. We have some local fixes for that which I can share, if desired.

I'm flagging this as a Private Security bug as a precaution, but I'd prefer for this to be public.

Kathy Lussier (klussier) wrote :

+1 to making this a public bug

Galen Charlton (gmc) wrote :

+1 as well. Unless somebody expresses an objection, I will make this bug a public security bug on noon EST on 27 April.

Galen Charlton (gmc) on 2017-04-27
information type: Private Security → Public Security
Andrea Neiman (aneiman) on 2017-05-10
tags: added: webstaffclient
Changed in evergreen:
assignee: nobody → Jeff Davis (jdavis-sitka)
Jeff Davis (jdavis-sitka) wrote :

Working branch user/jeffdavis/lp1684988-web-client-opt-in has a fix for this issue:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=947d0f27

On patron retrieval, an opt-in check is performed. If required, a dialog appears so that staff can opt-in the patron at their library. If opt-in is disallowed by the patron's home library, an alert message appears indicating that the patron cannot be retrieved. This fix works for me when retrieving a patron by barcode scan, patron search, and via item circ history.

NB: This fix does not prevent the patron search results grid from displaying personal information (name, address, etc.) for patrons who have not been opted-in. We should probably open a separate bug for that.

Test plan for regular opt-in boundaries:

1. Ensure the org.patron_opt_boundary org setting is set for your working location.
2. Attempt to retrieve a patron from outside the boundary. The opt-in dialog appears.
3. Click Cancel. The patron is not retrieved.
4. Retrieve the patron again. The opt-in dialog appears.
5. Click OK/Continue. The patron is opted-in and retrieved.
6. Retrieve the patron again. Thhis time, their account is retrieved directly since they have been opted-in.

Test plan for restricted opt-in:

1. Ensure the org.patron_opt_boundary org setting is set for your working location.
2. Set the org.restrict_opt_to_depth org setting for a library outside your opt-in boundary.
3. Attempt to retrieve a patron from that library. An alert message appears and the patron cannot be retrieved.

tags: added: pullrequest
Jeff Davis (jdavis-sitka) wrote :

My branch is based on master. A separate branch will be required for 2.12, since the fix modifies the patron search service, which was carved out of the main patron app in bug 1701001.

Changed in evergreen:
milestone: none → 3.0-alpha
assignee: Jeff Davis (jdavis-sitka) → nobody
Jeff Davis (jdavis-sitka) wrote :

Working branch user/jeffdavis/lp1684988-web-client-opt-in-2.12 has a fix for EG 2.12:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=c77c33ab

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Jason Etheridge (phasefx) wrote :

one gotcha when testing, the library setting alone is not sufficient, opensrf.xml's opt_in stanza has to be set to true.

Jason Etheridge (phasefx) wrote :

Looks good, thanks Jeff! Pushed to master with my sign-off

Changed in evergreen:
status: New → Fix Committed
assignee: Jason Etheridge (phasefx) → nobody
Jason Etheridge (phasefx) wrote :

Pushed to rel_2_12 as well

Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers