Subdomain as ecology.usegalaxy.eu https certificate error when using GxIT

[yvanlebras]

As GxIT are more and more used, it seems f interest to see if subdomain https certificate error can be fix.

[hexylena]

This has been a known issue since implementation with GxITs, unfortunately. :(

We had to manually add specific subdomains to the certificates to allow GxITs to function on those subdomains which was really not ideal.

I'd love to see this force us to switch more GxITs over to path based proxying, as that would let GxITs run on any subdomain + work for non-EU sites.

[yvanlebras]

Thank you Helena for your feedback! And to "switch more GxITs over to path based proxying", this is very complicated ? Sorry, clearly there, I don't know what it implies...

[hexylena]

According to galaxyproject/galaxy#14690 (comment) it should be as simple as "set requires_domain to false and test"

It requires that the GxITs will accept a request at any path, and then will properly use relative paths to access resources which doesnt apply to every GxIT, but hopefully to many.

[bgruening]

The deployment bit that we are working on is to have a traefik proxy in front of everything and get a wild-card certificate for that one. This would also solve this issue.

[hexylena]

The traefik proxy doesn't solve the original reason we didn't support GxITs on subdomains though. The problem was that you can't have multiple levels of wildcards in your certificate, so you're always stuck enumerating every single SAN you want, and then updating and re-issuing the certificate every time it changes. *.interactivetoolproxy.*.usegalaxy.eu isn't valid, sadly. So that's why we decided just for them working on one domain, to avoid the hassle of re-issuing every time we added a new domain.

The alternative, supporting path based proxying, would fix this here and for smaller sites that can't get wildcard sans

[yvanlebras]

Thank you for your messages Helena, Björn. Trying to find an easy solution, I have last, for sure stupid ;) sorry, idea... Is it possible when executing a GxIT from a subdomain, to "construct" the url without the subdomain ? I mean, deploying NEAL GxIT from ecology.usegalaxy.eu, give me this URL: https://ab5611c5b58fc3c6-58ca66106d784dee987e16969b5ae0e3.interactivetoolentrypoint.interactivetool.ecology.usegalaxy.eu/sample-apps/audio/ with a "your connection is not private" message BUT, if I manually remove "ecology." from the URL, I have this URL: https://ab5611c5b58fc3c6-58ca66106d784dee987e16969b5ae0e3.interactivetoolentrypoint.interactivetool.usegalaxy.eu/sample-apps/audio/ and it is ok, no ""security"" message who can frighten users...

There is no easy manner to force not writing the subdomain name in the URL?

[sveinugu]

@yvanlebras The basic support for path-based interactive tools is not yet fully merged all places it should be merged (PRs: galaxyproject/galaxy#15147, galaxyproject/gx-it-proxy#14, galaxyproject/gravity#96). Hopefully it will be part of the current release.

We are working on the last piece of the puzzle, which is to implement functionality for providing the full path to the Docker container. This is needed if the web server in the container needs this knowledge (e.g. is not only using relative links). This will in any case be available first in the next release.

What is working now is to configure an nginx proxy to understand path-based interactive tool URLs. It is described here (from "It is also possible to set up nginx to route path-based interactive tool URL" onwards): https://github.com/sveinugu/galaxy/blob/40cf2fcb706c645c4f4f55dab3f7303a0e0e8bef/doc/source/admin/special_topics/interactivetools.rst#server-side-configuration-of-galaxy-interactivetools

This documentation will be part of the new release, but the hack should work with previous releases.