Convert specific nginx statements to caddyfile - odoo

Help
1

1. Caddy version (caddy version):

v2.5.2 h1:eCJdLyEyAGzuQTa5Mh3gETnYWDClo1LjtQm2q9RNZrs=

2. How I run Caddy:

I have multiple domains:

jws.de, rectanglemaps.com, wir.live (and more to come)

They all point to localhost on port 8069, which is an odoo instance. Odoo then determines which website to respond with by using the headers that I set (previously I used nginx, but now I made the switch to caddy)

a. System environment:

Linux debian 11 (bullseye)
odoo runs in a docker-compose container, but that shouldn’t be the problem, it also worked with nginx

b. Command:

To start caddy:
screen -r caddy
sudo caddy start

To stop caddy
screen -r caddy
sudo caddy stop

c. Service/unit/compose file:

caddy doesn’t run In a docker container

d. My complete Caddyfile or JSON config:

#{
#	acme_ca htps://acme-staging-v02.api.letsencrypt.org/directory
#}

rectanglemaps.com {
	redir https://www.rectanglemaps.com{uri}
}

jws.de {
	redir https://www.jws.de{uri}
}

wir.live {
	redir https://www.wir.live{uri}
}

www.rectanglemaps.com, www.jws.de, www.wir.live {
	reverse_proxy http://127.0.0.1:8069 {
		header_up X-Forwarded-Proto https
		header_up X-Forwarded-Host {host}
		header_up X-Url-Scheme {scheme}
		header_up X-Real-IP {remote}
	}


	encode gzip zstd
	file_server
	log
}

3. The problem I’m having:

These headers are what odoo uses to identify which website the request is coming from (nginx)

 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Real-IP $remote_addr;

As you can see, I have tried to achieve the same with caddy by doing this

reverse_proxy http://127.0.0.1:8069 {
		header_up X-Forwarded-Proto https
		header_up X-Forwarded-Host {host}
		header_up X-Url-Scheme {scheme}
		header_up X-Real-IP {remote}
	}

Unfortunately, it doesn’t work yet. This probably means that I did not correctly “translate” the set headers from nginx to caddy file

4. Error messages and/or full log output:

No Error messages, odoo just responds with the default pages, which are set to “rectanglemaps.com”

5. What I already tried:

I have already searched for different ways to add the headers but I did not find anything useful. I also experimented with adding + signs (to tell caddy to add the headers?)

6. Links to relevant resources:

https://www.odoo.com/documentation/14.0/administration/install/deploy.html

2

You don’t need these, Caddy sets them automatically:

You probably don’t need these either, since Caddy already sets X-Forwarded-For and X-Forwarded-Proto which already have the relevant information.

It doesn’t make sense to add this unless you also tell Caddy which requests should be served as static files, and which should get proxied.

You probably just need this:

www.rectanglemaps.com, www.jws.de, www.wir.live {
	reverse_proxy /longpolling* 127.0.0.1:8072
	reverse_proxy 127.0.0.1:8069

	encode gzip
	log
}

Anyways, this doesn’t really seem like a problem with Caddy itself. You should probably reach out for help from Odoo to get them to document what might be missing.

Looking at their docs… did you try setting proxy_mode = True?

3 Likes
3

Thank you after editing my Config the way you suggested, it actually worked. Im guessing /longpolling was the problem.

Another question: Do you have a simple way in caddy redirect every domain that doesn’t come from www to www?

Basically that I dont have to do this:

rectanglemaps.com {
	redir https://www.rectanglemaps.com{uri}
}

jws.de {
	redir https://www.jws.de{uri}
}

wir.live {
	redir https://www.wir.live{uri}
}

for every website, instead just one block for every domain, something like this

[not www]domain {
        redir www.{domain}{uri}
}

Thank you for your help!

4

Not “safely.” (And that’s true of all web servers, I think. If you don’t want to list the hostnames then you have to accept all input.)

You could configure open redirects, but security scanners don’t like those (even though following redirects is a client problem, not a server problem; sigh).

I disagree with that camp though, and I’d say you could probably do this with on-demand TLS. You can’t use wildcard certificates because they aren’t subdomains.

If you really don’t want to enumerate hostnames, then something like this might work:

{
    on_demand_tls {
        ...
    }
}

*.* {
    tls {
        on_demand
    }
    redir https://www.{host}{uri}
}

I dunno. I think that’d probably work. @francislavoie or @Whitestrake might know a better way.

But honestly I wouldn’t recommend this, it’s a bit overkill when there’s just a few hostnames. If I were you I’d just explicitly map the redirects – way simpler.

5

This topic was automatically closed after 30 days. New replies are no longer allowed.