Closed sbesson closed 4 years ago
~It's probably https://github.com/ome/omero-gallery/pull/45 which means you need a (public) session~. Or maybe it's to do with caching? I'm surprised it worked before, AFAIK most webclient URLs require a login
For reference, comparing with the behavior of the public UoD SLS OMERO instance:
sbesson@ls30630:tmp $ curl -IL https://omero.lifesci.dundee.ac.uk/webclient/?show=project-27936
HTTP/1.1 302 Found
Date: Mon, 10 Aug 2020 13:35:57 GMT
Server: nginx/1.18.0
Content-Type: text/html; charset=utf-8
Location: /webclient/login/?url=%2Fwebclient%2F%3Fshow%3Dproject-27936
X-Frame-Options: SAMEORIGIN
Vary: Cookie
Strict-Transport-Security: max-age=31536000; includeSubDomains
HTTP/1.1 200 OK
Date: Mon, 10 Aug 2020 13:35:57 GMT
Server: nginx/1.18.0
Content-Type: text/html; charset=utf-8
Content-Length: 5156
X-Frame-Options: SAMEORIGIN
Vary: Cookie
Strict-Transport-Security: max-age=31536000; includeSubDomains
Set-Cookie: csrftoken=DbVVDLSDPZTNfx1NGkXPCKWGbVLpqWlmQLkyh5HRpIp0gtSyncDjeYboyiTSEf95; expires=Mon, 09-Aug-2021 13:35:57 GMT; Max-Age=31449600; Path=/
As said above, happy to migrate this discussion elsewhere.
I'm surprised it worked before, AFAIK most webclient URLs require a login
Hmm.... but it works in the browser. Is that because of cookies?
Probably that, along with the browser making a GET
not a HEAD
request. Note in the example in https://github.com/ome/ome-model/pull/118#issuecomment-671359445 you're redirected to the login page, not the webclient data browser. This is a valid request so you get a 200 code even though it's not the intended page. Also worth noting something like /webclient/?show=well-<ANY ID EVEN IF ITS INVALID>
will always return a successful HTTP status so we're not actually validating the URL.
For full reference, I think the change triggering this was https://github.com/sphinx-doc/sphinx/blob/v3.2.0/CHANGES#L85. As a side note, this might actually improve the overall experience of the model documentation linkcheck when testing the individual TIFF hyperlinks.
Following up on https://github.com/ome/ome-model/pull/118#issuecomment-671425814, we are also redirecting to the login page in the case of IDR URLs but as per https://github.com/IDR/deployment/blob/IDR-0.8.5/ansible/group_vars/proxy-hosts.yml#L255, this gets redirected back to the webclient which in turns redirects to the login page. So some infinite recursion is still happening
$ curl -IL https://idr.openmicroscopy.org/webclient/?show=well-771034
HTTP/2 302
server: nginx/1.18.0
date: Mon, 10 Aug 2020 16:09:52 GMT
content-type: text/html; charset=utf-8
content-length: 0
location: /webclient/login/?url=%2Fwebclient%2F%3Fshow%3Dwell-771034
x-frame-options: SAMEORIGIN
vary: Cookie
access-control-allow-origin: *
HTTP/2 302
server: nginx/1.18.0
date: Mon, 10 Aug 2020 16:09:52 GMT
content-type: text/html
content-length: 145
location: https://idr.openmicroscopy.org/webclient/?experimenter=-1
access-control-allow-origin: *
HTTP/2 302
server: nginx/1.18.0
date: Mon, 10 Aug 2020 16:09:52 GMT
content-type: text/html; charset=utf-8
content-length: 0
location: /webclient/login/?url=%2Fwebclient%2F%3Fexperimenter%3D-1
x-frame-options: SAMEORIGIN
vary: Cookie
access-control-allow-origin: *
HTTP/2 302
server: nginx/1.18.0
date: Mon, 10 Aug 2020 16:09:52 GMT
content-type: text/html
content-length: 145
location: https://idr.openmicroscopy.org/webclient/?experimenter=-1
access-control-allow-origin: *
HTTP/2 302
server: nginx/1.18.0
date: Mon, 10 Aug 2020 16:09:52 GMT
content-type: text/html; charset=utf-8
content-length: 0
location: /webclient/login/?url=%2Fwebclient%2F%3Fexperimenter%3D-1
x-frame-options: SAMEORIGIN
vary: Cookie
access-control-allow-origin: *
The recursion only occurs with a HEAD (-I
) request.
See https://merge-ci.openmicroscopy.org/jenkins/job/OME-MODEL-linkcheck/19/console
The latest release of Sphinx now fails the linkcheck for individual well URLs due a redirect excess. This can be reproduced using
This PR fixes the issue by using the canonical gallery study URL for the dataset provenance rather than the individual well.
There might be a large issue with the recursive IDR nginx redirects and I am unclear how this resolves in the web browser. @manics worth turning into an IDR/deployment issue or do you have a feeling for the source of the problem?