Qupath connecting to OMERO

Community Partners
, ,
#1

Hi I am making a new post to hopefully get some more eyes on this.

I am using Qupath 0.2.2 and I have an OMERO 5.7 instance that is behind a firewall and needs credentials to look at etc. When I try to follow the following directions https://omero-guides.readthedocs.io/en/latest/qupath/docs/qupath.html . I get stuck at Step 5. I get this message “Server returned HTTP response code 500 error for URL”. The URL works and is valid if I take the URL when I am logged into the system I can paste it in a new tab and it links to the image I want (I’ve tried this with multiple Images). I do not get to a login window and I would expect in step 7 so I am never given an opportunity in Qupath to enter my credentials. If I logout of our OMERO instance and use Images on our instance that are public, they open in Qupath without issue. How do I work around this? I think this might be similar to this post Opening Omero images through Qupath. and I had originally posted there but I as I am really stuck and need to solve this I am hoping this might be a more visible post.

2 Likes
Opening Omero images through Qupath
#2

Added some tags to improve visibility.

#3

Hi @susan-sheehan,

on the OMERO side, we’re not of anything that would cause the behavior you are seeing. If the limit to what you’ve seen so far is:

ERROR: OMERO web server: https://images.jax.org/webclient/?show%3Dimage-26476 - Server returned HTTP response code: 500 for URL: https://images.jax.org/webgateway/imgData/26476/

(from Opening Omero images through Qupath) then would it be possible to have your system administrator give you or send us the nginx error.log file?

All the best,
~Josh

1 Like
#4

after some failed attempts this morning, the error.log for the day is empty. We are seeing lots of “200” responses in the access.log

#5

Going to images.jax.org and logging in as the public user then browsing to https://images.jax.org/webgateway/imgData/26476/ does show me a 500 internal server error. But without logs, it’s pretty unclear what’s happening. Is there anything in OMEROweb.log? Is that URL showing up in the access.log? Any chance of of logs from the firewall server?

~J.

#6

I worked with out system admin for a while this AM. the Images.jax.org is a reverse proxy server for bhomero01lp.jax.org. We used this site today because it allows for better troubleshooting. I am unable to open any images. I get an unable to build server error but do not get the additional popup window of the 500 error. There are no errors from todays attempt, there were errors from prior days when I used the reverse proxy but none when I use the direct server address.

#7

Hey Josh, I am just starting to dive into this now. We are able to replicate @susan-sheehan’s error with QuPath. We do see things happening in the access.log. We saw your 500 errors, but that is what is expected if you try to access image data for which you don’t have permissions, correct?

The traffic we see coming from QuPath seems to show a mix of 200s, 301s with the occasional 500. I suspect the 301s are a http to https redirect but no luck on the 500 yet.

Can you remind me of a secure place to dump logs if we can’t get this sorted out?

-Dave

#8

I wouldn’t expect 50x for permissions error, no. See below.

Possibly also, but I’m starting from https. In my case the redirect is for logging in as the public user:

curl -IL https://images.jax.org/webgateway/imgData/26476/
HTTP/1.1 302 Found
Server: nginx/1.16.1
Date: Thu, 27 Aug 2020 06:23:30 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Location: /webclient/login/?url=%2Fwebgateway%2FimgData%2F26476%2F
Content-Security-Policy: object-src 'self' data:; img-src 'self' data:; default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; media-src 'self' data:; frame-ancestors http://localhost:8000
Vary: Cookie, Origin

HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Thu, 27 Aug 2020 06:23:30 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 5152
Connection: keep-alive
Content-Security-Policy: object-src 'self' data:; img-src 'self' data:; default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; media-src 'self' data:; frame-ancestors http://localhost:8000
Vary: Cookie, Origin
Set-Cookie: csrftoken=F5dPxbDwSLLcoTP7KVsc2JAzIhuf0AjmMbADkeZUaPZA2SE2UXhyqSE1vICVGfTf; expires=Thu, 26-Aug-2021 06:23:30 GMT; Max-Age=31449600; Path=/

Options include:

~Josh

#9

Ok we’ll do some testing to try to create useful logs. Thanks!

Just one more point of clarification, you being unable to access https://images.jax.org/webgateway/imgData/26476/ is expected behavior, because it is not in the public group. What response do you expect there?

#10

I take it back. I also see a 500 on our testing server. I’m surprised that that’s the case but nevertheless.

@susan-sheehan, you are currently logged in as yourself so you should see that image, correct?

Are you in multiple groups? If so, do you know if you are logged into a group other than the one the image is in?

~J

#11

Okay an update on this after working with @joshmoore on the nginx and omero.web logs.

@petebankhead @melvingelbard After sorting through some logging on the QuPath side in addition to the nginx and omero.web logs, we think that at least part of the problem is the 500 response that OMERO gives when there is a permissions error for imgData as described in Opening Omero images through Qupath Since OME is changing the response, I am not sure whether this is something that you all want to try to work around at this time. It’s difficult to determine if there are any other issues, but we’re happy to share the java logs if you’re interested.

We were encountering an entirely different error with another OMERO server that relates to the certificates being used, so that is on our end to fix.

Thanks for your help, everyone!

4 Likes
#12

Hi All,
Apologies - there was a bug in OMERO that returned a 500 Error when you are logged-in to OMERO but can’t find the specified image. You’re probably seeing this error because you have the public user configured on your server (automatically logged-n) but the public user doesn’t have permissions to access that image.
I’ve opened a fix for that at:


which currently returns a 404.

However, as discussed on the PR, I’m proposing to return a 403 if you’re logged in as the public user (same as when you’re not logged in at-all) which should then prompt Qupath to show you a login dialog. After logging in as yourself, you should be able to access the image.
Any feedback on that PR appreciated.

Once that fix is in omero-web, I’m hoping that Qupath will ‘just work’ once you’ve upgraded omero-web.
However it could be handy for Qupath to handle the current 500 error better, for usage with the existing omero-web behaviour for users who haven’t upgraded,

Regards,
Will

6 Likes
#13

With the recent release of omero-web 5.8.0, the webgateway/imgData/ID/ URL no-longer returns 500 if the image isn’t found: https://github.com/ome/omero-web/pull/209
Instead, it returns a 403 if you are not logged in. It also returns 403 if you are auto logged-in as public user but the image is not found (image isn’t public).
In either case, QuPath needs to show a login dialog and login to access the image.

However, when I tried this with QuPath 0.2.3 (and 0.2.2), I get this in the log:

INFO: Starting QuPath with parameters: []
ERROR: OMERO web server: https://omero.lifesci.dundee.ac.uk/webclient/?show%3Dimage-4378484 - Server returned HTTP response code: 403 for URL: https://omero.lifesci.dundee.ac.uk/webgateway/imgData/4378484/
WARN: Unable to open UriImageSupport (class qupath.lib.images.servers.omero.OmeroWebImageServerBuilder) support=4.0, builders=0
ERROR: Unable to build server: Unable to build ImageServer for https://omero.lifesci.dundee.ac.uk/webclient/img_detail/4378484/.

So it seems that QuPath is assuming that the Image is publicly available if the public user is configured on the OMERO.web server.
However, this is often not the case.
Instead, QuPath should directly try to access the /webgateway/imgData/ID/ URL and if this returns a 403 then offer a login dialog. Then try to access the URL after login.

Thanks,

Will.

6 Likes
#14

Hi all,

I have the same issue as @will-moore when trying to access to private OMERO images from qupath (the public user is configured on our OMERO.web server):
I tried with qupath 0.2.3 and 0.2.2., and it returns a 403 error, meaning that I am auto logged-in as a public user. However, qupath doesn’t show a login dialog to access the image as a private user:

ERROR: OMERO web server: https://omero.epfl.ch/webclient/?show%3Dimage-12553 - Server returned HTTP response code: 403 for URL: https://omero.epfl.ch/webgateway/imgData/12553/
WARN: Unable to open UriImageSupport (class qupath.lib.images.servers.omero.OmeroWebImageServerBuilder) support=4.0, builders=0
ERROR: Unable to build server: Unable to build ImageServer for https://omero.epfl.ch/webclient/img_detail/12553/?dataset=852.

Is there a way to make QuPath offer the login dialog for private images when the public user is configured on the OMERO.web server?

Best,
Claire

#15

Hi @stoffelc ,

Right now, unfortunately, the OMERO extension in QuPath doesn’t allow you to interact too much with the remote server. The current implementation will prompt an authentication dialog if the server returns 403 when requested the list of its OMERO projects (see here). If your server allows this (e.g. public user is configured on the server), QuPath will never prompt you for authentication and you will experience this error.

On the brighter side, we are currently working on drastically improving the OMERO extension which will, among other things, allow you to manage OMERO webclients in a much nicer/easier way. When this will be available, you should be able to connect to your server with your account and navigate between what is private and public on it as you wish.

This is currently in the testing stage so I don’t have a hard timeline on this. But hopefully (and with enough testing) it will be available in the next version of QuPath.

5 Likes
#16

Anxiously awaiting this functionality- thanks!

2 Likes