Issue: production redirects to staging url
Hi,
We've been using Kinde for authentication in our Next.js app since the end of last year. The app is hosted in Azure as a Web App, and within this Web App we have both a staging and a production slot. Each slot has its own set of env variables, including:
Ealier today, after performing a swap between staging and production in Azure, we encountered an issue: when users try to log in to the production app, they are immediately redirected to staging, even before the Kinde login page appears. As a result, users end up on staging instead of production.
No changes were made on our side to the Kinde version or configuration in the app, and this setup used to work without issues.
Could this behavior be caused by some form of caching that persists across the Azure swap, potentially on Kinde's side? Or is there something else we might be missing that needs to be reset or reconfigured?
To clarify, both the staging and production slot of the webapp use the same "Production" environment from Kinde.
Thanks in advance for any help!
3 Replies
Hi Maxime,
Thanks for bringing this to our attention. I’ll be discussing this internally with the team, but in the meantime, could you kindly help confirm a few things:
- Are all Kinde-related environment variables (
KINDE_CLIENT_ID, KINDE_CLIENT_SECRET, KINDE_SITE_URL, etc.) correctly marked as “Deployment slot setting” in Azure? This ensures the values don’t get swapped between environments unexpectedly.
- Could you check if users who are being redirected to staging have the x-ms-routing-name cookie set? This cookie can cause Azure to persistently route requests to the wrong slot.
- Please ensure that KINDE_SITE_URL, KINDE_POST_LOGIN_REDIRECT_URL, and KINDE_POST_LOGOUT_REDIRECT_URL are all correctly configured to use the production domain, both in your environment variables and in the Kinde dashboard.
- While unlikely to originate from Kinde’s side, if your application caches routing-related configuration (e.g., SSR/static generation), it may help to manually clear the cache or trigger a warm-up after swapping slots.
Let us know once you've had a chance to review the above, and feel free to share any relevant configuration screenshots if helpful — we're happy to take a closer look.
Hi Maxime,
Also, could you kindly provide the following details to help us investigate further:
- The production URL you're initially accessing
- The staging URL you're unexpectedly being redirected to
- The approximate time (including timezone) when you last observed the redirect issue
This will help us trace the behavior more precisely and determine if anything unexpected is occurring.
Looking forward to your response.Thanks for your response and the detailed pointers — much appreciated.
We've gone through your checklist:
All Kinde-related environment variables (e.g. KINDE_CLIENT_ID, KINDE_CLIENT_SECRET, KINDE_SITE_URL, etc.) are correctly configured and marked as “Deployment slot setting” in Azure for both staging and production environments.
The x-ms-routing-name cookie does not appear during or after the login redirect — we've checked this in the browser's devtools.
We have cleared the local caching of the Azure Web App manually, but unfortunately this did not resolve the issue.
We also tested by removing the staging URL from the list of "Allowed callback URLs" in the Kinde dashboard. In that case, some users were redirected to localhost, but we were unable to consistently reproduce this. On our end, we’re still being redirected to staging every time but with an error message (see below).
If we remove both the staging and localhost URLs from the allowed callback list, we consistently get the following error message:
"Looks like the allowed callback URLs in your Kinde application don’t include the one below."
So it seems Kinde still tries to redirect to the staging callback URL, even though the production environment and its variables are active and correct.
We’re happy to share more details or screenshots if that helps. We’d prefer not to share production or staging URLs publicly, but we’re happy to do so via private message or email if needed.
Hi, thanks again for your quick support!
We managed to resolve the issue by doing a clean build and deploy directly to our production slot, bypassing staging entirely. After that, everything worked as expected again.
For now, we're assuming the problem was caused by caching or slot-related behavior on Azure's side, possibly during the swap. We're reaching out to Azure support to investigate this further.
Appreciate your help in narrowing things down!
Hi Maxime,
Thanks for the update, really glad to hear that everything is working as expected after the clean build and direct deployment to production. It does sound like the issue may have been related to Azure slot behavior or caching during the swap.
If anything similar pops up again or if you need further assistance, feel free to reach out to us anytime. You’re also welcome to contact us directly at [email protected] for more in depth or private support.