Bug 38745 - Add a proof of concept JSON-RPC driven endpoint for RPC style calls that don't fit REST ideals
Summary: Add a proof of concept JSON-RPC driven endpoint for RPC style calls that don'...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Web services (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-18 17:06 UTC by Martin Renvoize (ashimema)
Modified: 2025-04-16 00:33 UTC (History)
2 users (show)

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


Attachments
Bug 38745: Add RPC Router (2.57 KB, patch)
2024-12-20 13:44 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 38745: Start adding a populate_empty_callnumbers RPC method (3.36 KB, patch)
2024-12-20 13:44 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize (ashimema) 2024-12-18 17:06:44 UTC
We have a few places where RPC style calls to perform various actions makes sense.. thinking 'bulk' actions and also 'test' actions for things like the sftp connection checks

I propose a distinct /rpc endpoint with a basic router built into the endpoint and oneOf being used to specify using the existing OpenAPI specifications.
Comment 1 Martin Renvoize (ashimema) 2024-12-20 13:44:41 UTC
Created attachment 175843 [details] [review]
Bug 38745: Add RPC Router

This patch add an RPC controller under the REST API to act as a router
for JSON-RPC 2.0 syle requests.
Comment 2 Martin Renvoize (ashimema) 2024-12-20 13:44:43 UTC
Created attachment 175844 [details] [review]
Bug 38745: Start adding a populate_empty_callnumbers RPC method

This patch takes the populate_empty_callnumbers method as proposed on
bug 38226 and modifies it for json-rpc expectations.
Comment 3 Martin Renvoize (ashimema) 2024-12-20 13:45:12 UTC
Very much a proof of concept for code and not usable yet
Comment 4 David Cook 2025-04-03 22:54:25 UTC
(In reply to Martin Renvoize (ashimema) from comment #3)
> Very much a proof of concept for code and not usable yet

I'm mostly liking what I'm seeing!

I've got one question and some feedback.

__Question__:
What would the "id" be in the payload? 

__Feedback__:

Based off on our past conversations, I ended up making an RPC-like endpoint a couple months ago (I wanted to just re-index N number of biblios from third-party tools), and the process brought up two issues: authentication and authorization.

Firstly, at a glance, it looks like you'd only be able to apply Koha permissions at the level of the RPC router, which won't be very fine-grained. I think this will likely cause problems for production/practical uses. 

Secondly, there's no validation of the action passed in the method, which means a caller could call any method for the target class (which is fortunately limited to Koha::REST::V1::, although that's still fairly coarse validation). 

I think we'd need to think up some further security controls here.
Comment 5 David Cook 2025-04-03 22:56:50 UTC
For my local one, I ended up creating a rpc_biblios endpoint with the intention that any user using that endpoint will have edit_catalogue permissions, and limiting methods to fall within that scope.

It does mean it's less flexible/powerful than it could be but it's reasonably secure (within the context of Koha's existing permission system...)
Comment 6 David Cook 2025-04-03 23:00:41 UTC
(In reply to David Cook from comment #4)
> I think we'd need to think up some further security controls here.

In all honesty, I think the API is calling out for this already. For instance, /api/v1/auth/password/validation needs a finer grained permission than it currently has. That's actually an endpoint that would probably work better as RPC too actually...