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

• https://github.com/MbinOrg/mbin/pull/1012
• https://github.com/MbinOrg/mbin/pull/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: https://github.com/MbinOrg/mbin/pull/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.