not
5494363221
CI / k8s (push) Successful in 8s
CI / lint (push) Successful in 5m15s
CI / build (push) Successful in 5m6s
CI / unit (push) Successful in 1m28s
CI / frontend (push) Successful in 3m17s
Deploy to Talos / deploy (push) Successful in 2m58s
CI / mutation (push) Successful in 5m2s
CI / verify-stack (push) Successful in 10m35s
## What & why Follow-up to #179. After login through `https://big-mijn.labs.respellion.tech`, the browser blocked the token request as mixed content. `KC_HOSTNAME_BACKCHANNEL_DYNAMIC=true` makes Keycloak build its token, userinfo and certs URLs from the incoming request. Behind the labs Caddy that request arrives as plain `http`, so the discovery document listed `http://big-auth…/token`. `KC_PROXY_HEADERS=xforwarded` makes Keycloak trust the `X-Forwarded-Proto: https` that Caddy sends. In-cluster calls (the BFF → `keycloak:8080`) carry no such header, so they are unchanged, and so is the localhost/NodePort setup. Refs #177 ## Definition of Done - [x] Linked Gitea issue (above). - [ ] Failing test committed before the implementation. *(One env var, verified live instead.)* - [x] Conventional Commits referencing the issue (`refs #NN`). - [ ] CI green - [x] Docs updated if behaviour, contracts, or operations changed. *(Comment in values.yaml.)* ## Notes for reviewers - I already applied this to the running cluster with `kubectl set env` and checked it. Both realms' discovery documents now have 0 `http://` URLs, and a `jan-burger` token from the public Keycloak still gets a 204 from the BFF. Merging keeps the next deploy from reverting it. - Keycloak now trusts `X-Forwarded-*` from anything that can reach it. Its only entry points are in-cluster callers and the NodePort, which the reverse tunnel exposes only to Caddy. `KC_PROXY_TRUSTED_ADDRESSES` could narrow that if the NodePort is ever exposed more widely. 🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #180