Why getSession (and customSession) don't include additionalFields?
@Better Auth
I dived deep into additionalFields, customSession and related concepts. This isn't about using infers for types, that works well for both server and client side.
It seems like even though adding additionalFields, even with returned: true (which is documented as: If the value should be returned on a response body.) it isn't returned to the client when the client calls getSession...
So I found here and there that additionalFields is only for the server side (then what is the returned field for??) and they are all stripped from getSession to client for "safety reasons".. It seems like an unnecessary limitation to me.. (Ping answered here but this isn't clearly documented anywhere else https://www.answeroverflow.com/m/1374165269303263244)
Okay, then I go for customSession and I nuke the config a bit fine, then I see that the customSession already provides the user and the session from params, but still without the additional fields
Whyyy. Why do I have to make two DB queries where the whole point of this additionalFields would be to avoid extra steps and roundtrips and neatly include the fields.. it already works for the server side why would you strip them away, and even in customSession? Then would it make a LOT more sense for customSession to not do any DB call and let us do that too?
I don't get this I feel like this should at least be easily configurable, like say with that returned field in additionalFields which I still don't know what is for.
I'am on latest. Or should I not experience this? If so I can raise a bug.
I dived deep into additionalFields, customSession and related concepts. This isn't about using infers for types, that works well for both server and client side.
It seems like even though adding additionalFields, even with returned: true (which is documented as: If the value should be returned on a response body.) it isn't returned to the client when the client calls getSession...
So I found here and there that additionalFields is only for the server side (then what is the returned field for??) and they are all stripped from getSession to client for "safety reasons".. It seems like an unnecessary limitation to me.. (Ping answered here but this isn't clearly documented anywhere else https://www.answeroverflow.com/m/1374165269303263244)
Okay, then I go for customSession and I nuke the config a bit fine, then I see that the customSession already provides the user and the session from params, but still without the additional fields
Whyyy. Why do I have to make two DB queries where the whole point of this additionalFields would be to avoid extra steps and roundtrips and neatly include the fields.. it already works for the server side why would you strip them away, and even in customSession? Then would it make a LOT more sense for customSession to not do any DB call and let us do that too?
I don't get this I feel like this should at least be easily configurable, like say with that returned field in additionalFields which I still don't know what is for.
I'am on latest. Or should I not experience this? If so I can raise a bug.
So I'm at my wit's ends, having scoured the web for a similar issue and having tried every config combination imaginable. It's not clear from the docs what is exactly expected to work "out of the box", so I'm hoping I can get more direction here.
What I'm trying to do: Simply extend the user object with a field.
```export const auth = betterAut...
What I'm trying to do: Simply extend the user object with a field.
```export const auth = betterAut...
Was this page helpful?
