I agree. It’s exciting to have an anonymous public API route. I suppose that it is a target for abuse… but that’s all the more reason to have that RESTPublicAnonymousRequests syspref – to give control to libraries about enabling/disabling that anonymous authorization.
David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel <[email protected]> On Behalf Of Tomás Sent: Wednesday, 17 June 2020 10:37 PM To: koha-devel <[email protected]> Subject: Re: [Koha-devel] Clarifying public routes on REST API Yeah, RESTPublicAnonymousRequests is the API counterpart of OpacPublic. On the public namespace you won't find permissions requirements, but things like 'allow-owner' and 'allow-guarantor'. About the biblios route, it is the first route to be really public and with anonymous access. I think it got backported, The RESTPublicAnonymousRequests follow-up bug should be backported as well I think. El mié., 17 jun. 2020 a las 0:18, <mailto:[email protected]> escribió: Hi Tomas, Looking at master, Koha/REST/V1/Auth.pm has a little maze of rules, which makes some sense. Looking at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24909, it looks like the public biblio endpoint doesn’t have x-koha-authorization defined and it is public, so either you’d need to be an authenticated user or have RESTPublicAnonymousRequests enabled. And that’s also available in 20.05 but not 19.11. Although in 19.11, it looks like public endpoints will work so long as no x-koha-authorization is defined for that route… interesting. Between your email and that code, I think that I follow now. Thanks! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel <mailto:[email protected]> On Behalf Of Tomás Sent: Tuesday, 16 June 2020 8:50 PM To: koha-devel <mailto:[email protected]> Subject: Re: [Koha-devel] Clarifying public routes on REST API 'public' routes, authenticated or not, are for unprivileged access i.e. the user doesn't need to have any special permission (a.k.a. flags). Public routes can be disabled (like when you turn off OPAC access) and can be enforced logged users (as in OPACPublic). Privileged access routes (i.e. non-public) always require login and permissions. For plugins it all depends on the author's decisions and coding. Hope it clarifies. Best regards El mar., 16 de junio de 2020 01:03, <mailto:[email protected]> escribió: Hi all, Could I get some clarification on the purpose of the “public” routes for the REST API? In the case of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24909, it looks like it’s a public API that doesn’t require authentication/authorization. However other “public” routes like /api/v1/public/* all require authentication and appropriate authorization. Are these denoted as “public” as we’re suggesting that only these routes should be used by third-party “public” systems? I don’t get it. Hoping someone can offer some clarification. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595
signature.asc
Description: PGP signature
_______________________________________________ Koha-devel mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
