[Bug]: When behind a proxy, opensearch.xml uses the proxied URL

[tliron]

What version of Degoog are you using?

0.24.0

What platform is it deployed on?

Rocky Linux

What steps can reproduce the bug?

curl myurl/opensearch.xml

What is the expected behavior?

No response

What do you see instead?

As you can see, the unproxied URL is used:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <ShortName>degoog</ShortName>
  <Description>Search</Description>
  <InputEncoding>UTF-8</InputEncoding>
  <Image width="16" height="16" type="image/x-icon">http://localhost:4444/public/favicon/favicon.ico</Image>
  <Url type="text/html" template="http://localhost:4444/search?q={searchTerms}"/>
  <Url type="application/x-suggestions+json" template="http://localhost:4444/api/suggest/opensearch?q={searchTerms}"/>
</OpenSearchDescription>

Additional information

There is a DEGOOG_BASE_URL environment variable, but per its description only the path is used.

I would expect to be able to set the full base URL for opensearch.xml.

[fccview]

Hey!
I built this so that degoog builds the urls from incoming request/proxy headers, that way it should work with zero-config across different hostnames (imagine one user hosting one instance in multiple clusters with individual different URLs). That env var is mostly for users running degoog on a sub path (e.g. domain.com/degoog)

I think I he issue is your proxy is forwarding localhost:4444 as host which means the app will use that, it's what it sees after all

You can fix this on your side easily by forwarding the X-Forwarded-Host and X-Forwarded-Proto, or preserve Host.

It could be worth adding an optional DEGOOG_PUBLIC_URL/DEGOOG_EXTERNAL_URL override, maybe, not sure if people would selfhost something without being able to configure their proxy but it could be a possibility, I'll have a think, I hate how many env variables are already there 😆

[tliron]

I see, that makes sense. However, it really depends on what reverse proxy you are using. I am using a hand-written one that does not set the X headers. :) But also, I think it's good to be able to override the URL for complex proxying situations. If the env variable is not set, then degoog can just ignore it and use its existing heuristic.

On that note, I think it can be a good idea to explain the heuristic in the documentation.

[fccview]

I see, that makes sense. However, it really depends on what reverse proxy you are using. I am using a hand-written one that does not set the X headers. :) But also, I think it's good to be able to override the URL for complex proxying situations. If the env variable is not set, then degoog can just ignore it and use its existing heuristic.

On that note, I think it can be a good idea to explain the heuristic in the documentation.

Yup, all VERY valid, I'll just accept this issue and work on it for next release ❤️

[tliron]

You are amazing and degoog is amazing. The UX is chef's kiss.

[tliron]

I discovered a related issue --

degoog does an auto-redirection to remove the trailing slash from a URL path set with DEGOOG_BASE_URL. However, as with opensearch.xml, it uses the internal URL. So the user gets redirected to a bad URL.

I might be missing something here, but I think we don't need a new environment var. Just have DEGOOG_BASE_URL really affect the entire base URL, and not just extract its path. That way I assume everywhere that a base URL is needed in the code should be the correct one (the one assigned by the env var).