I've finally got to take a deeper look why the OIDC login on packager dashboard ( https://pagure.io/fedora-infrastructure/issue/11861 ) fails. It seems sometimes this year (I unfortunately won't be able to pinpoint it more), our poor flask app behind gunicorn is getting doubled 'https,https' instead of 'https' in HTTP_X_FORWARDED_PROTO.
We're using haproxy.router.openshift.io/set-forwarded-headers: append which was necessary in the past. For now, I am going to implement an ugly workaround for that, but I'd be grateful for some guidance here. Is it expected? Is it issue app side in our stack (we're using pretty old Flask-OIDC)? Should we remove the haproxy (I can try it, just not right away)?
Thanks!
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops
@darknao any idea why we might be seeing duplicate PROTO here?
Can you see if changing the set-forwaded-headers changes anything? ie, unset it. set it to 'replace'.
I think append is the default now...
I don't think anything changed on OpenShift side. But something might have on Apache side on our proxies.
Ideally, each proxy in the chain (so both proxyXX.fp-o and the OpenShift proxy) should update the x-forwarded-* headers with the correct value.
In the past, our proxies did not set that header (or only on demand with the header_scheme ansible variable, not currently set for this app) so we configured OpenShift to add those headers with the set-forwarded-headers: append annotation on the route (The default setting in our cluster is never, which keeps the headers but never updates them).
header_scheme
set-forwarded-headers: append
never
What I think changed is that httpd now sets those headers by default, and OpenShift appends to them as configured (which is completely valid btw).
Log in to comment on this ticket.