Bug: /api/auth/setup is failing with 401 Unauthorized

[AntoLepejian]

Prerequisites

• I have searched the repository’s issues and Kinde community to ensure my issue isn’t a duplicate
• I have checked the latest version of the library to replicate my issue
• I have read the contributing guidelines
• I agree to the terms within the code of conduct

Describe the issue

Following the NextJS guide, I constantly see the following error in my console

This setup fetch call in this effect is always failing with 401 error.

The response just says "Login with Kinde".

At the moment it appears to be a red herring since I'm able to login anyways, but thought i'd report, since either the guide is missing a step, there's a bug with the SDK or I'm doing something wrong.

Thanks!

Library URL

https://github.com/kinde-oss/kinde-auth-nextjs

Library version

^2.2.10

Operating system(s)

macOS

Operating system version(s)

Sonoma 14.5

Further environment details

No response

Reproducible test case URL

No response

Additional information

No response

[AntoLepejian]

I just realised that this is 401ing only when there's no active user session, and once I login the request to /api/auth/setup succeed.

Sounds like a bug in the useEffect, which shouldn't fire if there's no active user session.

For reference, this is the problematic code

  const { user } = useKindeBrowserClient();

IIUC that's how I'm meant to check if a user is logged in or not, and hence there should be no call to /setup if it requires an active user session.

[DanielRivers]

This is current intended behaviour. Due to security measures the access token cookie is not readable by javascript so the browser knows nothing about the user. This /setup endpoint returns the data about the user based on cookie access token to the browser can setup the browser client.

The 401 happens when the user is not signed in as no token is present it doesn't have access to the route.

This is something we want to improve in the future.

[AntoLepejian]

I see thank you!

@DanielRivers should we handle the request rejection and swallow it then to avoid spamming the console?

If it's intended behaviour, there's a low-hanging fix to wrap it in a try/catch, and swallow the 401 errors? If it's any other status code we can rethrow.

Either way I'll leave it with you and the team 🙂

[DanielRivers]

Sadly, 401 errors cannot be omitted from the console. They are always outputted there is no way to prevent this.

[AntoLepejian]

TIL. I guess you'd have to return 200 { isLoggedIn: boolean } and reserve 401 for real unauthorised access attempts. Which is a slightly bigger job.

No worries then thanks for looking into this!

[davidf9265]

I totally agree with @AntoLepejian , i think this could be handled better, or at least being well documented. In my team, we spent a considerable time figuring out this wasnt an error on our side. Please improve this behavior, to allow us to really handle unauthorized states when they are really intended...

[DanielRivers]

Thanks for the feedback here, this is under discussion internally on improved flows here, care has to be taken as this could result in a breaking change.

[rizkysyahri]

Yep, I'm confused about this error, because this case is safe when local, but when deployed, the bug is there and I can't find a solution yet, is there a solution?