Bug 17424 - System preference to control access to own objects without permission
Summary: System preference to control access to own objects without permission
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on: 18137
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-11 11:18 UTC by Lari Taskula
Modified: 2020-03-17 21:33 UTC (History)
4 users (show)

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


Attachments
Bug 17424: REST API: Preference to control access to own objects without permission (11.83 KB, patch)
2016-10-12 11:54 UTC, Lari Taskula
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 17424: REST API: Preference to control access to own objects without permission (12.09 KB, patch)
2017-01-17 20:21 UTC, Josef Moravec
Details | Diff | Splinter Review
Bug 17424: REST API: Preference to control access to own objects without permission (12.18 KB, patch)
2017-06-16 09:24 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 17424: [QA Follow-up] Tiny tidy (2.30 KB, patch)
2017-06-16 09:24 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lari Taskula 2016-10-11 11:18:43 UTC
Introduce a preference to enable/disable access to own objects for patron's without required permissions.

Bug 14868 added "allow-owner" parameter that allows owner of the object to perform operations on themselves even if they do not have required permissions to otherwise do so (e.g. get own patron data or renew your own checkouts even if you don't have borrowers/circulating permissions). This means patrons can perform basic OPAC operations via REST API.

However, there should be an option to disable this functionality; as Katrin pointed out in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13895#c43 ,

> I can imagine both happening:
> - libraries wanting to shut down any OPAC account functionality, but still
> be able to renew in staff, so the circulation conditions are set up this
> way. In this case, there should be a way to lock the API (opacuserlogin
> might be a way)
> - libraries shutting down the OPAC, because they use something else like an
> external discovery layer. In this case they'd still want to use the API, but
> might turn off the OPAC as far as possible.

I propose a system preference for enabling/disabling access to own objects in REST API. This way libraries can disable opacuserlogin and any OPAC API functionality with the new preference. In the second case, libraries can disable opacuserlogin but still allow OPAC functionality via REST API.
Comment 1 Lari Taskula 2016-10-11 11:52:09 UTC
One problem with preference-approach is that it will create a mismatch between Swagger documentation and value of the preference if disabled. If the preference is being used to disable OPAC-like API operations, Swagger spec says they should still be possible. In this case, maybe it is enough to simply return an error message?
Comment 2 Lari Taskula 2016-10-12 11:54:17 UTC
Created attachment 56257 [details] [review]
Bug 17424: REST API: Preference to control access to own objects without permission

This patch adds a new system preference AccessOwnObjectsInAPI which controls
accessibility for OPAC-like REST API operations for patron's without otherwise
required permissions.

To test:
1. Apply this patch and set AccessOwnObjectsInAPI to "Enabled"
2. Test REST API operations that allow access to own objects. They should work
   as before. E.g. try to GET /api/v1/patrons/XXX where XXX is your borrowernumber
   (you need a valid CGISESSID, so login first, but make sure you don't have
    borrowers-permission)
3. Disable AccessOwnObjectsInAPI
4. Observe that you no longer have access. You should be given an appropriate
   error message for what happened.
5. Run t/db_dependent/api/v1/swagger/ownership.t and also other REST tests.
Comment 3 Josef Moravec 2017-01-17 20:21:33 UTC
Created attachment 59099 [details] [review]
[SIGNED-OFF] Bug 17424: REST API: Preference to control access to own objects without permission

This patch adds a new system preference AccessOwnObjectsInAPI which controls
accessibility for OPAC-like REST API operations for patron's without otherwise
required permissions.

To test:
1. Apply this patch and set AccessOwnObjectsInAPI to "Enabled"
2. Test REST API operations that allow access to own objects. They should work
   as before. E.g. try to GET /api/v1/patrons/XXX where XXX is your borrowernumber
   (you need a valid CGISESSID, so login first, but make sure you don't have
    borrowers-permission)
3. Disable AccessOwnObjectsInAPI
4. Observe that you no longer have access. You should be given an appropriate
   error message for what happened.
5. Run t/db_dependent/api/v1/swagger/ownership.t and also other REST tests.

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Comment 4 Marcel de Rooy 2017-06-16 09:24:07 UTC
Created attachment 64378 [details] [review]
Bug 17424: REST API: Preference to control access to own objects without permission

This patch adds a new system preference AccessOwnObjectsInAPI which controls
accessibility for OPAC-like REST API operations for patron's without otherwise
required permissions.

To test:
1. Apply this patch and set AccessOwnObjectsInAPI to "Enabled"
2. Test REST API operations that allow access to own objects. They should work
   as before. E.g. try to GET /api/v1/patrons/XXX where XXX is your borrowernumber
   (you need a valid CGISESSID, so login first, but make sure you don't have
    borrowers-permission)
3. Disable AccessOwnObjectsInAPI
4. Observe that you no longer have access. You should be given an appropriate
   error message for what happened.
5. Run t/db_dependent/api/v1/swagger/ownership.t and also other REST tests.

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 5 Marcel de Rooy 2017-06-16 09:24:11 UTC
Created attachment 64379 [details] [review]
Bug 17424: [QA Follow-up] Tiny tidy

The tests for $authorization keys allow_owner or allow_guarantor are
in the subroutines already. Moving the owner_guarantor test result in
a variable.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 6 Marcel de Rooy 2017-06-16 09:26:11 UTC
(In reply to Lari Taskula from comment #1)
> One problem with preference-approach is that it will create a mismatch
> between Swagger documentation and value of the preference if disabled. If
> the preference is being used to disable OPAC-like API operations, Swagger
> spec says they should still be possible. In this case, maybe it is enough to
> simply return an error message?

Life is hard :)
Comment 7 Jonathan Druart 2017-09-21 14:30:51 UTC
Please rebase this on top of bug 18137.
Comment 8 Tomás Cohen Arazi 2017-11-17 17:52:31 UTC
(In reply to Lari Taskula from comment #1)
> One problem with preference-approach is that it will create a mismatch
> between Swagger documentation and value of the preference if disabled. If
> the preference is being used to disable OPAC-like API operations, Swagger
> spec says they should still be possible. In this case, maybe it is enough to
> simply return an error message?

I think we need a more flexible approach: we need a configuration page in which users can select if they allow (or not) access to own (and relative's) objects, FOR EACH resource.

The OpenAPI docs can be adjusted to say it will depend on local configurations. And API consumers will notice anyway.