https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43030
Bug ID: 43030
Summary: Add generic own-resource (self-access) authorization
to the REST API
Initiative type: ---
Sponsorship ---
status:
Product: Koha
Version: Main
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5 - low
Component: REST API
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected]
Target Milestone: ---
This patch adds a generic mechanism for REST API endpoints to allow access to a
caller's own resources without requiring the broader module permission (for
example, a staff member managing their own lists, or viewing/editing their own
patron record, without list_borrowers/edit_borrowers).
Today, authorization is all-or-nothing: an endpoint's x-koha-authorization
block requires a specific module permission, with no way to grant reduced
access based on ownership of the record. Several controllers (Lists,
AdvancedEditorMacro, Patrons/Password, Patrons/SelfRenewal) work around this
today with inconsistent, ad hoc ownership checks that do not share a common
implementation.
This patch introduces:
- Koha::Object->is_owned_by($patron) and Koha::Objects->owned_by($patron), a
shared ownership interface implemented per class (identity based for
Koha::Patron, owner field based for Koha::Virtualshelf)
- An allow-owner flag on x-koha-authorization, checked in Koha::REST::V1::Auth,
that admits an authenticated caller lacking the module permission when the
resource is their own
- Koha::REST::Plugin::Objects integration so objects.find and objects.search
enforce/scope by ownership automatically, without each controller
reimplementing the check, and while continuing to support paging, embeds, and
existing query parameters
- Write path guards so a caller admitted only via ownership cannot create a
resource owned by someone else or reassign ownership away from themselves
Permission continues to take priority: a caller who holds the module permission
is unaffected and retains full, unrestricted access exactly as today. Ownership
is only consulted for callers who lack the permission.
Initial scope covers the Lists (virtualshelves) and Patrons endpoints, chosen
to exercise both ownership shapes (owner field and identity match). Other
existing ad hoc self checks are left as follow up work.
Test plan:
1. Apply the patches and run the test suite for the affected modules: prove
t/Koha/Object.t t/Koha/Objects.t t/db_dependent/Koha/Virtualshelves.t
t/db_dependent/Koha/Patrons.t t/db_dependent/api/v1/patrons.t
t/db_dependent/api/v1/lists.t
2. As a staff user without any list/shelf permission, confirm GET /api/v1/lists
returns only your own lists, and GET /api/v1/lists/{id} succeeds for your own
list and returns 403 for someone else's
3. As a staff user without borrowers permissions, confirm GET and PUT
/api/v1/patrons/{patron_id} succeed for your own patron_id and return 403 for
another patron_id
4. As a staff user with the relevant module permission, confirm both endpoints
behave exactly as before (full, unrestricted access)
5. Confirm creating/updating a list while lacking the module permission cannot
set the owner field to another patron
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
