Trusted Proxies breaks HTTPS schema in Docker

[privacyguard]

Describe the bug
After upgrading to 1.7.1, SSO logins on our production environment started failing due to a wrong redirect_uri. The HTTP schema in the redirect_uri started getting set to HTTP instead of HTTPS. This is related to the TRUSTED_PROXIES configuration.

We made sure the environment variable was set correctly (as described in the docker setup documentation):

TRUSTED_PROXIES=::1,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

Our reverse proxy was correctly adding the x-forwarded-proto header but the header seemed to be getting lost somewhere.

It is possible that the docker/caddy/Caddyfile might be missing the trusted_proxies option for the reverse proxy header to be considered.

Temporary Workaround
We commented out the x-forwarded-proto trusted header from config/packages/framework.yaml

Related PRs

• Add trusted proxy config to framework configuration #1012
• Add trusted proxies to docs #1086

Which Mbin version was running on the instance?
1.7.1

To Reproduce
Steps to reproduce the behavior:

1. On a docker production environment (with a reverse proxy and https)
2. Upgrade to 1.7.1
3. Setup an SSO provider
4. Login with SSO
5. The redirect_uri schema becomes http which fails SSO authentication

Expected behavior
The redirect_uri schema should remain https based on the "HTTPS=TRUE" environment variable in docker compose.

[melroy89]

Thanks for the bug report.

There is effort made to actually also redo the whole docker setup, see PR: #1085
(still a draft, and taken over from somebody else who left)

It's advised for now to use bare metal setup if possible.

We uncommented the x-forwarded-proto trusted header from config/packages/framework.yaml

Uncommented? You mean commented (so removing x-forward-proto as trusted header)?

[privacyguard]

Thanks. Yes we meant "commented out" not "uncommented". Edited.