Summary: | Add a proof of concept JSON-RPC driven endpoint for RPC style calls that don't fit REST ideals | ||
---|---|---|---|
Product: | Koha | Reporter: | Martin Renvoize (ashimema) <martin.renvoize> |
Component: | Web services | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | dcook, martin.renvoize |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30652 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38226 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39637 |
||
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
Bug 38745: Start adding a populate_empty_callnumbers RPC method |
Description
Martin Renvoize (ashimema)
2024-12-18 17:06:44 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. 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... |