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.
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.
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.
Very much a proof of concept for code and not usable yet
(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.
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...)
(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...