sbesson
commented
1 year ago My understanding is that the code introduced in #15 resolves the base URL passed by the initial request call sent by the client and uses it to make a secondary request call within the deployment itself to retrieve the content of another deployment.
Currently idr-next.openmicroscopy.org is not a public DNS and even the idr-next deployments do not know about it. So any internal request to https://idr-next.openmicroscopy.org/searchengine/api/v1/resources/ will fail with a resolution error e.g.
[sbesson@prod110-proxy ~]$ curl https://idr-next.openmicroscopy.org/searchengine/api/v1/resources
curl: (6) Could not resolve host: idr-next.openmicroscopy.org; Unknown errorA few immediate options:
- publishing the DNS. This would bring idr-next in parity with idr-testing/idr. That's the solution with the smallest amount of code changes but it modifies our approach wrt embargo data as we should assume any data loaded on idr-next can be available publicly (even if it's not production ready)
- update the code to use relative URLs rather than resolving the domain as the internal endpoint should be available e.g.:
[sbesson@prod110-proxy ~]$ curl http://localhost/searchengine/api/v1/resources/ OMERO search engine (API V1) - update the code to make the query at the JS level rather than at the Python level. This means that all the calls would be made from the browser.
/cc @francesw @jburel
will-moore
See https://github.com/IDR/deployment/pull/388
For the mapr redirect logic, we need to look-up Map-Ann Keys for a given value, added in https://github.com/IDR/idr-gallery/pull/15
This works OK on idr-testing and idr production, but not on idr-next, since the idr-next searchengine is not available from where the Django code is running.