Closed usrbinpikachu closed 5 years ago
I see the after the 307, your server is responding with a 303 redirect. Not 100% sure why. I have to look to it and try to reproduce the problem here.
@kudakeru Can you confirm how you have your apps configured with Auth0? Do all of the backends have a callback url that exists in the list of Allowed Callback URLs
in your Auth0 Application configuration?
That's correct, yes. Each of our services has a sub-domain, and a callback URL at that sub-domain.
To summarize from the slack conversation. This issue showed itself after issue #6 was resolved with the latest image tag ambassador_pro:auth-0.0.6
.
You have Ambassador setup to route based on the host header to your back-end apps, each with their own subdomain e.g.
subdomain1.dev.domain.com
subdomain2.dev.domain.com
subdomain3.dev.domain.com
Each of these subdomains have callback URLs listed in the Allowed Callback URLs in your Auth0 Application configuration.
Only subdomain1.dev.domain.com
's callback URL is identified in the AUTH_CALLBACK_URL
environment variable in your Ambassador Pro configuration.
You are experiencing an issue where requests to subdomain1.dev.domain.com
get authorized correctly but a request to any other sub-domain will be stuck in auth loop.
@kudakeru I am copying this from slack:
Quick question for you about the behavior you're looking for with multi-domain login. Do you want single sign-on across all domains where domain1.example.com
will use the same token for domain2.example.com
so signing into one domain signs you into all? Or should each domain require their own sign in?
Requests to services behind Ambassador other than the service that lives at AUTH_CALLBACK_URL successfully initiate an auth request to Auth0, but continually redirect back to the auth page after successfully logging in. I've attached a screenshot of the Chrome dev console network viewer per @gsagula's request.