Key
Error with typescript app detecting wrong hostname ?
After our login-demo app using the next middleware forwards to
GET https://login.foo.com/oauth/v2/authorize?client_id=289301738480009300&scope=openid%20email%20profile%20offline_access%20urn%3Azitadel%3Aiam%3Auser%3Ametadata&response_type=code&redirect_uri=https%3A%2F%2Flogin-demo.foo.com%2Fapi%2Fauth%2Fcallback%2Fzitadel&state=xlfcfYDhU9io7B4i1zlsTP-FxBYHsu9nQAbaPtevIXo&code_challenge=zX6uooEi8ixzVk6_VOxxzmmgXMThOgNfX092SP-Xl0E&code_challenge_method=S256 the login app forward me to https://login-ui-8644fb44f5-fr8km:3000/accounts?authRequestId=V2_289367805545939075 effectively breaking the login
Is there a way that the typescript code should pickup the real Host / X-Forwarded-Host for this?
10 Replies
@peintnermax can you please advise
@peintnermax any idea?
Hi @Endre | Blackr4t , where does the
https://login-ui-8644fb44f5-fr8km:3000 come from? could you send me your proxy configuration? 🤔@peintnermax I'm using Traefik with GatewayAPI ontop of Kubernetes but sure
@peintnermax Do you know though what's the expected headers? 🤔
We have documented the required headers for the new login here: https://zitadel.com/docs/guides/integrate/login-ui/typescript-repo#oidc-proxy
We require a
x-zitadel-client-name header which is the id of your service user
x-zitadel-public-host should point to login.foo.com, and
x-zitadel-instance-host defines the host of your instance.ZITADEL Docs
To replace our current golang built login UI and showcase the use of our new resource, session and OIDC APIs, we've created the Typescript Repository.
@peintnermax yes that is for
login -> zitadel communication, but the issue now seems to be that request.nextUrl.host is not being set to the value of the incoming Host header this means for example that
1. Proxied requests via the middleware.ts file towards zitadel will get wrong x-zitadel-public-host
2. Redirects / other things where the login app responds back to the client will get the wrong Host in the URLcould you set up these headers / rewrites in traefik and remove the middleware of the login app? You dont have to use nextjs if you have a custom proxy..
Hmm, good point actually
@peintnermax But that's just some of the calls though, what about the redircts also that happen that also seem to be reliant on it?
"/.well-known/:path*",
"/oauth/:path*",
"/oidc/:path*",
"/idps/callback/:path*", are not relevant for the login itself so you could use traefik to forward them 🙂@peintnermax yeah I know that, but those are not the problem anymore anyways, we're still at the root problem still really which is that NextJS seems to ignore setting request.nextUrl.host to the incoming Host header for some reason and that causes the other later redirect() calls to give the wrong value for the host