microservices cross-origin headers

[will-moore]

IDR includes CORS headers in all standard responses, allowing sites at other origins to consume JSON, Images etc.

However, it seems that this is not the case with micro-services, so that when I try to view a rendered image from a page at another origin, this is now fails:
E.g. when working on idr-gallery locally, it is configured to load images from IDR. This still works for thumbnails but not full images:

cc @khaledk2

[joshmoore]

Don't see anything mentioned on https://github.com/search?q=repo%3Aglencoesoftware%2Fomero-ms-image-region%20cors&type=code

I imagine something like:

Router router = Router.router(vertx);

router.route().handler(CorsHandler.create("*"));

would be necessary (as a configurable option). See https://stackoverflow.com/a/52420183/56887

[sbesson]

Note that as per #176, the responsibility of setting the CORS headers has been shifted to the NGINX layer rather than the OMERO.web Django framework.

That should be relevant to the micro-service since the same configuration is handling the routing of the relevant /webgateway/... calls.

From the above Access-Control-Allow-Origin: * is set as part of the Response headers. In the context of your local application, what else is required for the calls to be processed successfully?

[will-moore]

Hmmm - OK, thanks for that.
I can't seem to work out what's going on in the example above and what CORs fixes are required...
But let me take a step back to my original issue that prompted me to try the test above...

I've been working on a summer side project to start a mobile-friendly web app for OMERO, initially using a static hosted site loading IDR data via public JSON and image urls...

Have a look at https://omero-skye.netlify.app/
Over the summer, I was loading images with simply webclient/render_image/IMAGE_ID/0/0/ without any rendering query string. Although the plan was always to add rendering query string, it was handy to use this just to get started. This was working fine until the micro-services were deployed on IDR last week.

Now, when I try to load images with webclient/render_image/IMAGE_ID/0/0/ I get a 403.
E.g. I go to https://omero-skye.netlify.app/dataset/10276/image/9837232 I see this (NB: the low-resolution image is simply the thumbnail as a placeholder - the full rendered image doesn't load)

This is looking at img requests.

If right-click on the broken image and open the image in a new Tab, e.g. https://idr.openmicroscopy.org/webclient/render_image/9837232/82/0/ then I see that the micro-services rejects this with Must provide channels in parameter 'c' and a 400 Response.
I think that render_image without query parameters is still supported in omero-web, since it didn't get removed following discussion at ome/omero-web#443 (comment)

Anyway, I added the query-string to the render_image URLs, so now I'm using URLs like https://idr.openmicroscopy.org/webclient/render_image/9837232/82/0/?c=1|5:50$FF0000,2|0:200$00FF00&m=c&p=normal&ia=0&maps=[{%22inverted%22:{%22enabled%22:false}},{%22inverted%22:{%22enabled%22:false}}]
When I open that in a new Tab, I get a couple of different behaviours when I've tried this at different times/images:

• Either it renders just fine and I see the image. Then I can go back to my app page, refresh the page and the image loads fine.
• Or, I still see a 403 Permission Denied response to the render_image request. This persists until I view the image in IDR. E.g. I go to https://idr.openmicroscopy.org/webclient/?show=image-9837232 and open the Preview tab. Now, when I refresh the page at https://idr.openmicroscopy.org/webclient/render_image/9837232/82/0/?c=1|5:50$FF0000,2|0:200$00FF00&m=c&p=normal&ia=0&maps=[{%22inverted%22:{%22enabled%22:false}},{%22inverted%22:{%22enabled%22:false}}] it renders OK! Then, I can go back to https://omero-skye.netlify.app/dataset/10276/image/9837232 and it renders the full-resolution image OK.

I don't know what causes the difference in these 2 behaviours - maybe I'm just hitting different readonly servers at different times.

Anyway, this seems to be not quite a CORS issue on the client, but a server-side issue that is returning a 403 response from a cross-origin request, but once the response has been cached on the server then the same render_image URL will work cross-origin. If you change the rendering settings or Z/T then you get a 403 response again.

It's also possible to replicate this in any html page, e.g https://jsbin.com/ if you enter

You get a 403 response.

[sbesson]

I think that render_image without query parameters is still supported in omero-web, since it didn't get removed following discussion at ome/omero-web#443 (comment)

Yes, I think this is related to ome/omero-web#440 and a series of issues raised by work on the rendering endpoints in the micro-service and discussed at the weekly OMERO.web meetings. The micro-service is more strict on some query parameters e.g. channels are required but OMERO.web was not modified.

I don't know what causes the difference in these 2 behaviours - maybe I'm just hitting different readonly servers at different times.

That's highly unlikely unless your IP is changing in between your calls

Anyway, this seems to be not quite a CORS issue on the client, but a server-side issue that is returning a 403 response from a cross-origin request, but once the response has been cached on the server then the same render_image URL will work cross-origin. If you change the rendering settings or Z/T then you get a 403 response again.

I also suspect this is not an CORS issue. Instead I think is related to the logic to retrieve the OMERO session key from the OMERO.web cookie in https://github.com/glencoesoftware/omero-ms-core/blob/14b01cd7c4c4d27cf9cb065236a52b6314dc4835/src/main/java/com/glencoesoftware/omero/ms/core/OmeroWebSessionRequestHandler.java#L76-L119.