Session cookie not updating
I'm not totally sure what is going on. I augmented my session table to include my own organization data as well as the users timezone.
After a user is logged in, if they don't have an active organization, my middleware routes them to a page where they can choose an organization to use. When the user selects the organization an endpoint is called that updates the value in the session table.
I then call the
getSession function with the disableCookieCache: true on the server. I saw in a Github issue that using that should refresh the cookie with the new data that is in the session table. When I log the results of that server side call to getSession it looks great. It's exactly as I expect with the active organization and the timezone set properly.
Once the server side call is done I run a getSession withe disableCookieCache on the client side as well, once again the session object looks great. I then use router.push to go to my dashboard.
However, when I get the session in the middleware, using the recommended method with betterFetch, the session object does not have the active organization set nor does it have the timezone set, even if I use disableCookieCache: true. I don't understand what is going on.
My best guess is that there is some caching going on somewhere either in Next or in Better-Auth that is giving me an old cookie.
I need a fresh right-out-of-the-oven cookie!
Any help would be much appreciated.
Thanks!6 Replies
is this specefic to the middleware?
also you may want to use
auth.api.getSession instead if you're on next version 15.2 or higher@bekacru It turns out it wasn't the middleware. It was the session cookie not being set. When I signed in with email the session gets set. This then takes me to the page where I can choose an account. I choose the account and my own api endpoint updates the session object. I called the
auth.api.getSession with disabledCookieCache:true on the frontend. It gives me the correct session back however it does not update the cookie.
In the response headers there was no Set-Cookie header. For more context. I have the two additional fields set on the session in the auth config. I also have a customSession plugin which didn't do anything besides rearrange the data structure. I found out that if I remove the customSession plugin then the getSession call sets the cookie.
Two things tipped me off to it. First I stepped through the better-auth source code and saw that the customSession plugin calls getSessionFromCtx and passes the returnHeaders: false but then never sets the cookie after that. Second is this Session caching, including secondary storage or cookie cache, does not include custom fields. Each time the session is fetched, your custom session function will be called. from the documentation. That paragraph is confusing because what I thought were custom fields were actually called additional fields. I'm assuming custom fields only come from the customSession plugin.
It was pretty easy for me to remove the customSession plugin so I solved my problem. However, customSession not putting the results in the cookie doesn't make sense to me. I definitely wanted it cached so that I didn't have to call getSession with disabledCookieCache:true every time. But I'm sure there is a reason why you guys did it this way.
Thanks for the response and the library!
Also may I suggest a change to the documentation. In addition this Session caching, including secondary storage or cookie cache, does not include custom fields. Each time the session is fetched, your custom session function will be called.
Maybe include To properly use the customSession plugin you must call getSession with disabledCookieCache:true or else you will not get the custom fields back from the plugin in the session.Enabling cookie cache should prevent it from returning data defined in
customSession. If it's not the case, it's likely a bug. We did not intended customSession to run only when the cookie cache is disabled.Ok then it seems to be functioning as you intended. That behavior doesn't make sense to me though. I assumed that when I have the customSession plugin then any session I get, whether in the cookie cache or not, would have the custom session data in it. It took me a very long time to figure out that that was not the case. My suggestion would be to change the behavior of it or make it explicitly clear what the purpose of the customSession plugin is in the docs. I'm still not sure why you wouldn't want the custom fields in the cookie cache.
Cookies can only contain a limited amount of data. And mostly people use custom session to return a lot of data with the session. So for the time we opt out from storing it on a cookie cache altogther but we should have an option to be able to store custom data as well sometime soon.
That makes sense. Thank you!