Reverse Proxy body off

[firecow (Mads Jon Nielsen)]

firecow_forward_auth

reverse_proxy https://sso.firecow.dk {
    method GET
    rewrite /auth

    header_up Host {upstream_host}
    header_up X-Forwarded-Method {method}
    header_up X-Forwarded-Uri {uri}
    header_up X-Forwarded-Proto {header.X-Forwarded-Proto}

    @good status 2xx
    handle_response @good {
        request_header Remote-User {rp.header.Remote-User}
        request_header Authorization {rp.header.Authorization}
    }
    handle_response {
        copy_response_headers {
            exclude Connection Keep-Alive Te Trailers Transfer-Encoding Upgrade
        }
        copy_response
    }
}

Caddyfile

:80

route {
    import cego_forward_auth
    reverse_proxy {$CADDY_UPSTREAM}
}

Heya, I’m trying to discontinue my forward-auth plugin GitHub - firecow/caddy-forward-auth: Forward auth middleware for caddyserver
Since Caddy 2.5.1 now has handle_response in reverse_proxy.

In nginx, and also the firecow forward_auth plugin, the request body isn’t forwarded to the sso.

proxy_pass_request_body off;

I can’t seem to find an Caddy directive to prevent the body from being shipped to the reverse_proxy.
Do you guys know of one such directive ?

[francislavoie]

We’re working on the docs for this right now:

docs: Changes for v2.5.1 release

If you use method GET, then the body is implicitly turned off. We turn it off if the method is being rewritten to GET or HEAD. That makes for the simplest possible config, I think.

@firecow

    header_up X-Forwarded-Proto {header.X-Forwarded-Proto}

You don’t need this – Caddy already sends this header:

reverse_proxy (Caddyfile directive) - Caddy Documentation

You can shorten your entire config to just this:

forward_auth https://sso.firecow.dk {
	header_up Host {upstream_hostport}
	uri /auth
	copy_headers Remote-User Authorization
}

[firecow (Mads Jon Nielsen)]

Epic stuff
It’s working perfectly, and without any ugly plugin,

I’ll let people know in firecow/forward_auth README.md, that this method is the way forward, thank you very much…

Why isn’t header_up Host {upstream_hostport} the default behavior of forward_auth directive btw?
I’m just asking because it took me quite a while to figure out, why cloudflare which my sso.firecow.dk is behind kept giving me 403. (cloudflare don’t allow “bogus” host headers)

[francislavoie]

@firecow

Why isn’t header_up Host {upstream_hostport} the default behavior of forward_auth directive btw?

Because it’s only needed if you’re proxying over HTTPS. See the docs:

reverse_proxy (Caddyfile directive) - Caddy Documentation

Most people will be proxying over HTTP, probably. Like Authelia users who are self-hosting it in their own network. If they used authelia:9091 as their upstream address and had that header_up line, then the Host would become authelia:9091 which doesn’t make sense – it’s a better default to pass through the original Host header.

[firecow (Mads Jon Nielsen)]

Ok, thanks for the quick answer.