Configuration API returns unexpected values for by_host option

[ElectronicBlueberry]

Describe the bug
/api/configuration does not return the correct themes, if the themes are set per host.
This behavior leads to the themes not being selectable for users on subdomain configurations.

Galaxy Version and/or server at which you observed the bug
Galaxy Version: 23.0 - dev

To Reproduce
Steps to reproduce the behavior:

1. Set themes_config_file_by_host in the galaxy configuration to two different hosts. localhost and 127.0.0.1 can be used for local testing
2. Create two different theme files for these hosts
3. Run galaxy
4. Go to each of these URLs, and see that the default theme for each configuration is applied
5. call /api/configuration for each of these URLs, and observe that the themes do not match the set, or displayed themes

Expected behavior
/api/configuration reflects the correct configuration per host

Additional Context
The configuration inlined in the client html behaves as expected (see #16455), which is why the default theme is applied correctly.

[davelopez]

Sorry I forgot I assigned myself to this one 🤦‍♂️

I'm just checking 23.0 branch and I couldn't find themes_config_file_by_host in the configuration schema. Is this an intended undocumented configuration option? or should we add it to the config schema?

[bgruening]

It is themes_config_file the by host extension is a feature that is enabled if you want by host configurations.

#12328

[davelopez]

Ouch, I didn't know that... I guess those dynamic config options will need to be taken into account in the future Pydantic model #16518

[mvdbeek]

In the response model you shouldn't know about per_ and just return the correct one, but yes, the parsing needs to account for these.

[davelopez]

I think I might have found the reason why it is not discriminating the by_host value as expected in this particular situation. I debugged using localhost and I found:

When getting the config through the UI controller we are using WSGI and request.host is localhost:8081 (expected)

But when using the API endpoint we are going through the ASGI request which internally translates request.host to 127.0.0.1.

That is why we always get the by_host match to 127.0.0.1 when using the API. I guess this will only affect this particular test scenario and should work with proper sub-domains.

[ElectronicBlueberry]

It is confirmed to be broken with proper subdomains as well.

[davelopez]

Interesting... Hmmm, the logic itself looks fine, it would be useful to see what is in the request.host variable for those sub-domains. If the issue is still the same and it resolves them to the same IP in the ASGI request, then we probably need to use another way of discriminating the host.

[mvdbeek]

The solution is probably somewhere in the ASGI to WSGI middleware, if it works on old-style request objects.

[mvdbeek]

yep, it's in the host header, the logic in the webob.Request class is this (_host__get is a property assigned to Request.host):

    def _host__get(self):
        """Host name provided in HTTP_HOST, with fall-back to SERVER_NAME"""
        if 'HTTP_HOST' in self.environ:
            return self.environ['HTTP_HOST']
        else:
            return '%(SERVER_NAME)s:%(SERVER_PORT)s' % self.environ

and the logic in the middleware is this:

    # Go through headers and make them into environ entries
    for name, value in scope.get("headers", []):
        name = name.decode("latin1")
        if name == "content-length":
            corrected_name = "CONTENT_LENGTH"
        elif name == "content-type":
            corrected_name = "CONTENT_TYPE"
        else:
            corrected_name = f"HTTP_{name}".upper().replace("-", "_")

we could do the same, or we could use request.base_url.netloc (where request is a starlette Request instance).

[davelopez]

Definitely a big bug... 😓
I think #16574 will return the correct host now. I tested it with the themes and it works like the old-style request.

[davelopez]

Should be fixed by #16574