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.
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?
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.
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>
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>
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>
(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 :)
Please rebase this on top of bug 18137.
(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.