search

auth0 / nextjs-auth0

Next.js SDK for signing in with Auth0
MIT License
2.08k stars 391 forks source link

4.0.0-beta.2 getSession returns null #1804

Closed jimseiwert closed 5 hours ago

jimseiwert commented 1 week ago

Checklist

Description

following the documentation on the readme for login. Everything works correctly redirecting to /auth/login and back. No errors on the callback. In the onCallback there is a session object. When you are on a server component and run the below code it returns null for the session

Reproduction

  1. setup per instructions on the readme
  2. go to child route using app router and use the following code

import { auth0 } from "@/lib/auth0" const session = await auth0.getSession() ` return ( <>

Welcome, {session.user.name}!

);`

Additional context

No response

nextjs-auth0 version

4.0.0-beta.2

Next.js version

15.0.3

Node.js version

22.9.0

guabu commented 1 week ago

Hey @jimseiwert 👋 The getSession() method returns null only if the user is not authenticated.

Could you share a complete minimal reproduction so I can help look into it? At first glance, nothing seems wrong with the snippet you shared but it's not enough to know what the setup looks like.

jimseiwert commented 1 week ago

@guabu - Here you go, basic repo with the same behavior. https://github.com/jimseiwert/redesigned-system

guabu commented 1 week ago

Thanks @jimseiwert! I've just tested out your repro and it's behaving as expected:

(I've tested this in Chrome and Safari)

When you are on a server component and run the below code it returns null for the session

This is only the case when the user is not authenticated (does not have a session).

If you have any more details on how you're getting in this state to help reproduce it, please let me know so I can try to reproduce it!

jimseiwert commented 1 week ago

Could it be an app setting in the dashboard I am missing? Here is a screen recorder of the behavior in chrome using the same repo I shared

The logs show success

image

jimseiwert commented 1 week ago

Just for context, this same app works on v3 of the auth0 sdk

guabu commented 1 week ago

Thanks for the additional context.

Could it be an app setting in the dashboard I am missing?

It should work on any new, default tenant — have you tried with another tenant just to rule that out?

Are you seeing any logs from your server or browser that might help narrow it down?

jimseiwert commented 1 week ago

so a new tenant worked with no code changes. I am comparing the settings now to see if I can identify the difference.

jimseiwert commented 1 week ago

Found the issue, looks like my tenant was set to an older version of node.... node 12 👎

Changing this to 18 fixed the error for me. Hope this helps someone else

jimseiwert commented 1 week ago

I was wrong, that did not fix the issue, it was just a delay in the auth clearing. I am able to switch between the two tenants. One with a null session being returned and one that works (the new tenant). New apps in the old tenant do not work either. At a loss for what could be the cause.

guabu commented 1 week ago

so a new tenant worked with no code changes. I am comparing the settings now to see if I can identify the difference.

It seems that we've narrowed it down to the issue being related to the tenant/client setting.

I noticed that the client you're using has an Application Type of SPA and a token_endpoint_auth_method of none. Could you please make sure to create a Regular Web Application in your tenant please and give that a try (see docs)?

jimseiwert commented 1 week ago

I compared tenants and all the tenant setting and application level settings match each other. The only difference now is the tenant domains .auth0.com vs .us.auth0.com

IN v4 when I hook to the beforeSessionSaved hook and the onCallBack hook I see the session data. Just when I call await auth0.getSession() is it null for the old tenant. Is there a new data attribute the new tenant has that the old one does not that the sdk is looking for?

VeigarMid commented 1 week ago

Same Issue here, using 4.0.0-beta.3. Happening on an older tenant as well, that is a Regular Web Application.

guabu commented 1 week ago

@jimseiwert @VeigarMid after you've completed authentication, could you confirm if you have the __session cookie set with the following properties?

cookies

jimseiwert commented 1 week ago

There is no cookie after login. I do see the session data in the onCallback(error, context, session) but no cookie is saved

VeigarMid commented 1 week ago

Hi @guabu, just want to confirm that today I've re run the same use case and now it's working correctly. I fear that this was caused by a misconfiguration on the callback url. I was testing using localhost as callback, but the experiment that gave getSession null was executed with a mobile phone connected on the same wifi. So when I ran the experiment reaching the site on 192.168.1.66 the callback redirected towards localhost:3000/auth/callback?code=1234..., giving no chance to the nextjs app to authenticate correctly the user. I apologize for adding noise, I think this is the expected behaviour from nextjs-auth0. Thanks and have a beautiful day

jimseiwert commented 1 week ago

Hi @guabu , I have found the cause. In our tenant we have an action that adds additional claims to the id and access token based on the user. When you have an action with the v4sdk that sets the accessToken it breaks the getSession call.

You can reproduce this by adding a post-login trigger event with the below code

api.accessToken.setCustomClaim(namespace + 'foo', event.user.name);

guabu commented 6 days ago

Hey @jimseiwert 👋 I'm glad you managed to resolve the issue!

I've tried adding the Action with the custom claim as you shared and I was able to login and received the access token with that claim present.

Do you have any custom code in your application beyond the sample you shared above (https://github.com/jimseiwert/redesigned-system) that might be contributing to this?

jimseiwert commented 6 days ago

Hi @guabu, No, I keep using that sample since it has the bare minimum. I have noticed it is intermittent depending on when the action runs or not (event.authorization).

Would there be any settings I am overlooking for injecting additional claims at runtime? I tried even on the beforeSessionSave callback and had the same experience where I would see the session then add my claim and it would not save the cookie.

I also updated to beta 7 to see if that fixes some of the items. The same code base works on v3 of the sdk.

jimseiwert commented 6 days ago

@guabu - Happy to jump on a call or give you a test app in the tenant if you want to test side by side

guabu commented 6 days ago

Hey @jimseiwert 👋

I have noticed it is intermittent depending on when the action runs or not (event.authorization).

Based on this and that it occurs across all applications in this tenant but not the newly created tenant, I suspect this might be related to the Actions/Rules in your tenant adding additional data to the access token and causing it to go over the cookie size limit enforced by browsers (usually 4KB).

Could you:

  1. Completely disable the Action and any Rules/Hooks you have for that tenant and let me know if this resolves the issue for you?
  2. Share any extensibility code you have for that tenant (Actions, Rules, Hooks) — please be sure to redact any sensitive information.

Would there be any settings I am overlooking for injecting additional claims at runtime?

I believe it's not related to a specific setting but perhaps related to the above since the user can successfully authenticate but the cookie is not "sticking".

Thanks for being so patient while we try to get to the bottom of the issue 🙇 I understand the back-and-forth can be frustrating!

ltatakis-optaxe commented 6 days ago

@guabu just to add here I am experiencing a similar problem. We have a post login hook Action in Auth0 that adds three small custom claims

api.idToken.setCustomClaim(`.....roles`, assignedRoles)
api.idToken.setCustomClaim(`https://....com/organization`, event.organization)
....

then extract that data from the user returned in useUser.

Running the app on 3.5.0 I get the claims come through in the user data ( from the useUser hook ) but then moving to to 4.0.0-beta.7 none of them come through.

Same codebase, same tenant, same creds.

Which as @jimseiwert mentions it either feels there is some new setting we are missing that we need to enable OR the lib is not pulling them through for some reason. Given you say you can see them, there must be some setting missing somewhere for this?

guabu commented 6 days ago

Hey @ltatakis-optaxe 👋 This sounds like a separate issue here if I understand correctly. @jimseiwert is mentioning that the session cookie is not set after the user has authenticated whereas it seems in your case that the ID token does not get the custom claims set.

For the particular case your mentioning, you will need to use the beforeSessionSaved to propagate the claims to the user profile, like so:

export const auth0 = new Auth0Client({
  async beforeSessionSaved(session) {
    // filter out the claims however you like and set them on the user object
    return {
      ...session,
      user: {
        ...session.user,
        foo: "bar",
      },
    };
  },
});

This is documented here but perhaps we can make it more clear: https://github.com/auth0/nextjs-auth0/tree/v4?tab=readme-ov-file#beforesessionsaved

This is done to avoid adding all the ID token claims and bloating the cookie which was a common source of issues in v3.

ltatakis-optaxe commented 6 days ago

@guabu that did indeed fix my issue. Thank you. Some better docs around that would be appreciated.

I am sorry for side tracking the thread in this case. 🙇

guabu commented 6 days ago

Definitely, I'll update the docs so it's more clear — thanks for the feedback!

jimseiwert commented 4 days ago

Hi @guabu - after much digging we can close this issue as it is not a problem with the sdk.

Based on this and that it occurs across all applications in this tenant but not the newly created tenant, I suspect this might be related to the Actions/Rules in your tenant adding additional data to the access token and causing it to go over the cookie size limit enforced by browsers (usually 4KB).

The above was the issue. It appears the old domain sent much more data with the token vs the new domain. I am not sure why it worked on v3 of the sdk but not v4 but that is a problem for a different day. After restructuring and removing the items I don't need use the beforesessionsaved event solved my issue.

Thank you for the help troubleshooting this. Maybe a suggestion in the sdk would be to check the size and throw a warning/error if not created?

guabu commented 4 days ago

Great! I'm glad we managed to get to the bottom of that one — sorry it took some time, it was a tricky one to track down!

Thank you for the help troubleshooting this. Maybe a suggestion in the sdk would be to check the size and throw a warning/error if not created?

I definitely agree here, we'll need to show a warning so it's more clear and easier to troubleshoot. I'll make sure this gets added in the next release!

Thanks again for your patience throughout this!

guabu commented 6 hours ago

Warning log has been added to v4.0.0-beta.8 when the cookie size exceeds 4096 bytes.