javascript: Infinite redirect loop in NextJS development environment

We’ve noticed. that certain users have bad cookie values which causes the infinite loop.

The cookie name is __client_uat and the bad value is 0 instead of some timestamp like 1692272951

Once we clear this cookie the redirect loops are gone.

Our observation of this cookie is that it gets a bad value when we switch between the subdomains of our app - Production / Staging.

This was with version @clerk/nextjs==4.19.0, seems fixed in @clerk/nextjs==4.21.13

I am using “@clerk/nextjs”: “^4.23.2” this version and still getting the error… If anyone knows how to fix it please do let me know

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Thank you very much, it turns out that toggling “Set time automatically” and “Set time zone automatically”, with synchronizing the time, and properly setting my time zone did the trick.

This was with version @clerk/nextjs==4.19.0, seems fixed in @clerk/nextjs==4.21.13

We are experiencing the exact same error since releasing our production environment. The issue might be tied to the __client_uat cookie which is available twice if both the develop and the main instance are running on the same domain.

We have the following scenario:

• development on a.b.c.mysite.io
• main on app.mysite.io

This is the cookie we see on main:

• __client_uat = <timestamp>

This is what we see on develop:

• First cookie, domain “a.b.c.mysite.io”: __client_uat = <timestamp>
• Second cookie, domain “.mysite.io”: __client_uat = 0

Once one has visited the main site with their browser and switches to develop to test something, the site is trapped in an infinite loop with the error referring to the said cookie, ie.

The Cookie '__client_uat' has been rejected for invalid domain.

We have to painfull clear the cookies, refresh everything and refrain from accessing the live site in the same session. It never occurs on localhost. Anybody else having this issue?

(Node v18.17.0, @clerk/nextjs v4.29.3, in Docker)

I was getting this error when using node v20, switching back to 18 resolved it for me

I got this error after switching auth providers to Clerk, I got it to work by clearing my old cookies.

@stx-chris @creative-tutorials @jameslporter After digging heavily into Next’s internals, as well as performing a number of tests with SSL termination and reverse proxying, I’m fairly confident that the PR we submitted to Next.js earlier today, will solve these issues.

Currently, the PR is approved and, once merged, the changes will be available as a canary build of v14.0.3.

In the meantime, you should should be able to mitigate these issues by setting the X-Forwarded-Host request header to the Host header via Varnish, or otherwise.

This was my configuration via Caddy:

localhost {
  reverse_proxy localhost:3000 {
    header_up X-Forwarded-Host {host}
  }
}

In short, if X-Forwarded-Host is already set, Next doesn’t overwrite it with the incorrect value.

I am using “@clerk/nextjs”: “^4.23.2”. I have changed the time and time zone and I still getting the same error … Does anyone have a solutions?

On my windows PC, syncing with the time server solved the issue. It might occur again, but I am good for now

I got the same problem. Fresh install of T3, installed clerk, followed quick start docs, first npm run dev and i got this error. Tried everything. Skewing time updating, checked keys. It doesn’t work

I just ran into the same issue after updating my node to v.21. I resolved the issue by downgrading node to v.18 and updating nextjs to v.14.1.0. Hope this might help someone!

cleared cookies, changed node version (v18.18.2), and she works :–) thanks all

After changing node 20.10.0 to node 18.12.1, it working fine.

I had same issue but I solved it.

The following is what we did this time.

• switch to node v18.18.2 (current latest version)
• install latest version of @clerk/nextjs
• update packages.

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Thank you very much, it turns out that toggling “Set time automatically” and “Set time zone automatically”, with synchronizing the time, and properly setting my time zone did the trick.

thanks when i setup then restart computer that okay;

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Tried syncing my time, still the same issue

Mainly

For me upgrading to @clerk/nextjs=4.29.7,next=14.0.4 did not help, but eventually clearing cookies and localstorage did

It happened only in development or even the production?

It only helped for the initial page load but same issue after I refreshed. I have figured out the final fix now. Seem to be a Nextjs Issue. Upgrading to 14.1.3 solved the issue eventually. vercel/next.js#55648

Mainly everyone should just upgrade to Next.js 14.1.3. It worked for me as I upgraded as well.

Yes, upgrading my Next.js (‘^14.2.1’) worked for me. Just do npm install next@latest and it should install the latest Next.js which should resolve this issue with clerk.

For me upgrading to @clerk/nextjs=4.29.7,next=14.0.4 did not help, but eventually clearing cookies and localstorage did

It happened only in development or even the production?

It only helped for the initial page load but same issue after I refreshed. I have figured out the final fix now. Seem to be a Nextjs Issue. Upgrading to 14.1.3 solved the issue eventually. https://github.com/vercel/next.js/issues/55648

I just ran into the same issue after updating my node to v.21. I resolved the issue by downgrading node to v.18 and updating nextjs to v.14.1.0. Hope this might help someone!

This will help a lot. Thanks!

But I want to know who else is still having this issue. I’m on node v.20.10.0 and I haven’t noticed these issues for a long time, it comes back yes, but when I sync my time, I don’t notice it again. The issue only comes back whenever I run into a low battery on my laptop.

We are also having this issue. Still have no clue how to fix it.

I’m running into this on node v21.6.1

Try syncing your clock please

I still have this issue. I have cleared cache and cookies, I have gone from node v21 to v18, I have changed date and time on and off. I am using localhost:3000

I was getting this error when using node v20, switching back to 18 resolved it for me

Thanks, It worked for me. i was on node v21, switched back to 18 and it’s working

If only the people who knew the answer were here to help. Godspeed and good luck! Maybe if you share more about your docker setup we can find out what isn’t quite right.

On Wed, Nov 15, 2023, 9:47 AM stx-chris @.***> wrote:

Ok in that case our issues are different, because local development and build work fine and we don’t get any token-related issues. It’s the same with Next v13 and v14.

But once we build our Docker image and upload it to Google Cloud, with the only difference being the Next.js version, Clerk’s url debug value is http://localhost:3000 within the Docker container on v13 and https://localhost:3000 on v14 and the error reason we receive is cross-origin-referrer, which is expected in that case.

— Reply to this email directly, view it on GitHub https://github.com/clerk/javascript/issues/1436#issuecomment-1812782957, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAG5UEROSQUJLHYRVLKZ6TYETPYNAVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSG44DEOJVG4 . You are receiving this because you were mentioned.Message ID: @.***>

Nope I’m on 14 as well. It’s not a code problem. It’s how you are running it. Again the only way I’ve gotten it to work properly for http localdev is to use localhost:3000. Getting kind of frustrated with the lack of support here. I feel like I’m the clerk support staff trying to help others through the problems I experienced. I really just want confirmation that my hypothesis is correct and if so this be stated clearly in the documentation. My requests have fallen on deaf ears.

On Wed, Nov 15, 2023 at 9:30 AM stx-chris @.***> wrote:

thx @jameslporter https://github.com/jameslporter , seems to be related to changes in Next v14, see my comment in #2115 https://github.com/clerk/javascript/issues/2115. It might be a recently introduced bug in Next 14 or an issue with how Clerk determines the current protocol and hostname.

— Reply to this email directly, view it on GitHub https://github.com/clerk/javascript/issues/1436#issuecomment-1812752449, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAG5UDPU5UVDYYBFRBYDK3YETN27AVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSG42TENBUHE . You are receiving this because you were mentioned.Message ID: @.***>

I"m using Windows 11. I changed my time and time zone. I cleared the cache and cookies and I’m still getting the same error. Then I tried another web browser and still the same…

Did you add debug: true (see https://github.com/clerkinc/javascript/issues/1436#issuecomment-1668728895)? If so, what were the results of the log?

We’ve noticed. that certain users have bad cookie values which causes the infinite loop.

The cookie name is __client_uat and the bad value is 0 instead of some timestamp like 1692272951

Once we clear this cookie the redirect loops are gone.

Our observation of this cookie is that it gets a bad value when we switch between the subdomains of our app - Production / Staging.

Is your staging using Dev keys from Clerk? If so, we would recommend either:

• using production keys (sharing the user base) for staging so the cookies are the same
• using a second domain and a second, free Production instance for staging to have a limited user base.

@emLuc86dev maybe this https://github.com/clerkinc/javascript/issues/1566 is the cause of your bug? it also causes infinite loop but for a different reason that the timezone one

On my windows PC, syncing with the time server solved the issue. It might occur again, but I am good for now

Does anybody encounter it on production app? where end users doesn’t sync with time server from windows settings? I mean, We developer fixing it on our device but what if it happens same with end users ? Where they didn’t sync with time server?

(Mine also fixed with time server sync)

If you are experiencing this in NextJS, please add debug: true to your authMiddleware. See https://clerk.com/docs/nextjs/middleware#middleware-argument-types. This will give you debugging loads which can produce more information.

If you see an error like the one below, then it is indicating your clock is out of sync.

[0] "message": "JWT issued at date claim (iat) is in the future. Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)"