https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24861 --- Comment #5 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to David Cook from comment #3)
What's the difference between a "public" and "non-public" Koha API endpoint? I haven't been able to observe any difference.
Public routes are not expected to have 'permissions' required (i.e. they don't need privileged access). For example, a patron should be able to see some of its checkouts information, but can only see others if it has admin rights to see that. A possible approach was to have a big IF in the controller for /checkouts, but we decided to have /public/patrons/:patron_id/checkouts which wouldn't require 'permissions' (in Koha's sense) but requires the requestor to be the resources owner (i.e. identified as a real patron and matching the patron_id with its borrowernumber).
With RESTBasicAuth enabled and using the username and password for patron #42:
curl -u <username:password> http://localhost:8080/api/v1/public/patrons/42/password -d '{"old_password":"OLD","password":"NEW","password_repeated":"NEW"}'
{"error":"Authorization failure. Missing required permission(s).","required_permissions":null}
Perhaps I'm doing something wrong but this looks like a bug to me?
It works for me on master.
With that same syntax? The documentation isn't clear.
You shouldn't need any different syntax. How are you testing this? cURL? Postman? Try Postman with Basic authentication, just in case.
I'll have to try again. I've noticed RESTBasicAuth doesn't work with CGI, so maybe I was trying it on a non-Plack Koha, and that's why it was failing.
I submitted a patch to fix your non-Plack issue, or I meant to and forgot. Can you double check? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.