[Koha-devel] REST API not working in koha-testing-docker?

dcook at prosentient.com.au dcook at prosentient.com.au
Fri Mar 13 07:50:30 CET 2020


Ah, interesting. I haven’t drilled down that far yet. I’ve been doing lots of multitasking and out of the office. Probably won’t have a chance to look at this again for at least a few days minimum.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Agustin Moyano <agustinmoyano at theke.io> 
Sent: Friday, 13 March 2020 4:36 PM
To: dcook at prosentient.com.au
Cc: Tomas Cohen Arazi <tomascohen at gmail.com>; koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] REST API not working in koha-testing-docker?

 

As Tomas says, I've seen in many endpoint controllers that the code is wrapped by a try, but in the catch section $_ is ignored, and a 500 is returned. 

 

I believe that Tomas means is that you should concat $_ to the message of the 500 error in that catch section.

 

Regards.

 

On Thu, Mar 12, 2020 at 8:05 PM <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:

Hey Tomas,

 

I listed some steps to reproduce at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24862. I haven’t drilled down deep enough yet, but I’m thinking it might relate to cookies for anonymous sessions. 

 

Can you elaborate on what you mean by “concat $_ to the case of 500”? 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of Tomas Cohen Arazi
Sent: Friday, 13 March 2020 9:52 AM
To: koha-devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] REST API not working in koha-testing-docker?

 

Hi all.

 

Cookie auth shouldn't be a problem per se. We only use the cookie for getting the user and then the code is the same no matter the autentication method.

 

But

 

There's always a 'but', right?

 

I've been fighting some devs that introduce the use of C4::Context->userenv and then probably have side effects of a cookie is found ... Even if the api is called using (say) oauth.

 

We should get rid of this side effects from our codebase. In the meantime, share some more info on the endpoint you're hitting so we can debug it and fix it!

 

Cheers

 

PS I need to submit some work I did for handling unhandled exceptions in a more useful way. I suggest you concat $_ to the case of 500 on the endpoint you're using to get more info.

 

El jue., 12 de marzo de 2020 19:31, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

Hi Arthur,

 

Thanks for your comprehensive reply. Sorry I just noticed it after replying to everyone else who CCed me directly.

 

I’m not interested in using browser extensions, but thanks for sharing your experience. 

 

It looks like the 500 Internal Server Errors probably related to Koha not handling a cookie/browser session as expected. The errors went away if I used a different browser or an Incognito mode. (Hence why it also worked with curl.) I suppose that could be a bug in Koha, but probably not a significant enough one to deal with right now. 

Sure enough, when I log into the http://localhost:8080, I can now get the output of http://localhost:8080/api/v1/libraries because of the cookie indicating my browser session. If I log out, I now get ‘{"error":"Something went wrong, check the logs."}’, when really I should probably get a 401. Raised this issue for it https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24862. 

 

The RESTPublicAPI thing also looks like a bug as I keep getting this error: {"error":"Authorization failure. Missing required permission(s).","required_permissions":null}. At least when I try using RESTBasicAuth. I haven’t tried with RESTOAuth2ClientCredentials or cookie authentication. I’ll probably just end up blocking RESTPublicAPI anyway, but I’ve raised a ticket anyway https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24861. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of Arthur Suzuki
Sent: Thursday, 12 March 2020 8:23 PM
To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
Subject: Re: [Koha-devel] REST API not working in koha-testing-docker?

 

Hi David,

To test Rest API I strongly recommend the use of "RESTer" which is an extension for Firefox.

I'm sending here the "requests collection" I've made for my own use.

When you open RESTer, there is a menu on the right (if not, click on the top left 3-bar icon).

First thing is to go on "Organize" and import the request collection.

2nd step : Click on "Environment", then + button in the lower right corner.

For the requests in the collection to work you'll want to define an environment called "koha" with a key called "baseurl" containing... the base url of the koha instance you want to test, for koha-testing-docker this is http://localhost:8080

This setup allow to quickly change the baseurl for another one (let say a client in prodution) for all the requests in the collection.

401 is Authentication Failure error, this is how I solved :

3rd step : click on a request from the "KohaTest" group.  You'll get a panel with "Headers/Body/Auth/Var" tabs where you can provide data to forge the request.

Go to Auth tab, click on "Generate new Token" -> "Basic" and provide credentials (koha/koha)

To use basic Auth of course you'll have to enable BasicAuth in the Syspref.

Click on the newly generated token so that it has a tick on its left.

If you want to use curl, then you can easily export stuffs from RESTer to Curl, click on the top-right "3-point vertical" button and select "Show curl command" -> gives the curl stuff.

I find this way of working very useful to maintain the collection of curl commands.

Sry that this email is a bit long, it may not directly solve your issue but I hope it may :)

If there is any interest I can maybe make a screencast to show how to setup the whole thing.

I'm now just pulling the last koha-testing-docker env to verify if I get same errors as you have (taking some time given my very poor bandwidth in the middle of nowhere ^^)

Best regards,

Arthur

On 12/03/2020 05:41, dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  wrote:

Hi all,

 

I’m finally getting around to playing with the REST API, but it’s not quite working as expected.

 

In koha-testing-docker (with the latest koha-testing-docker git repo and Docker images as of this writing), I’m getting the following in the browser:

 

1.	200 OK

a.	http://localhost:8080/api/v1/.html
b.	http://localhost:8080/api/v1/ or http://localhost:8080/api/v1/.json 

2.	500 Internal Server error (with no obvious messages in the server logs other than a missing “Routing to a callback”)

a.	http://localhost:8080/api/v1/items
b.	http://localhost:8080/api/v1/patrons
c.	http://localhost:8080/api/v1/libraries

 

If I use “curl” or a Perl script, then I get a 401 error instead of a 500 error. (Although in Koha 19.11, I can get JSON results in either the browser or with curl for those endpoints, but that’s a whole other matter.)

 

RESTBasicAuth = 1 means I can use the API via curl, but still nothing via the browser. Which is fine I guess in practice but it’s not really what you’d expect. I often use browser requests to test out GET requests for APIs. 

 

I don’t really get how RESTPublicAPI works either. If it’s disabled, it says ‘{"error":"Configuration prevents the usage of this endpoint by unprivileged users"}’, but that doesn’t seem accurate, since disabling that system preference blocks the /public APIs in general, right? Even if you use a privileged user, it still doesn’t work.

 

Actually, even with RESTPublicAPI enabled, I can’t get the /public endpoints to work. I get errors like this ‘{"error":"Authorization failure. Missing required permission(s).","required_permissions":null}’. 

 

This email is getting a bit long and I think I have a million other API problems, so I might just work through one by one and open Bugzilla tickets as I go…

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

 

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
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/

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200313/0f8e528a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200313/0f8e528a/attachment-0001.sig>


More information about the Koha-devel mailing list