Ability to pass additional data to auth context.
How can we pass additional data from say sessions claims to auth context. With Clerk in other scenarios like prisma/trpc, we used to be able to store things we frequently access on the userProfile in session claims, and are able to pass this along to trpc context, and get access to it in all routes. But with convex, no matter what I add to the session claims, it seems everything is striped, except what's defined on the UserIdentity interface. The problem with this, is that it means for every table in our db, if there is any association to a userProfile, we would always have to first fetch the userProfile by it's authUserId(subject/tokenIdentifier), then use the _id field value of the returned userProfile to make any associations.
Current work around is to either store the userProfileId on the client context, and pass that along with every query or mutation, or what we are instead doing is using authUserId as the main relationship key everywhere.
The ideal scenario is what we had before, where when a user is created, we store the userProfileId is Clerk's privateMetadata or publicMetadata, then pass that along with session claims, and use some of the values from session claims to construct the user identity. So now, every authenticated call already has the db userProfileId, role, userType, etc. And we can go about using it in all queries and mutations without first reaching to the db to fetch the userProfile by the Clerk authUserId for every single request.
Would love any suggestions on what you all are doing instead. Or if I am missing something.
Thank you.
Current work around is to either store the userProfileId on the client context, and pass that along with every query or mutation, or what we are instead doing is using authUserId as the main relationship key everywhere.
The ideal scenario is what we had before, where when a user is created, we store the userProfileId is Clerk's privateMetadata or publicMetadata, then pass that along with session claims, and use some of the values from session claims to construct the user identity. So now, every authenticated call already has the db userProfileId, role, userType, etc. And we can go about using it in all queries and mutations without first reaching to the db to fetch the userProfile by the Clerk authUserId for every single request.
Would love any suggestions on what you all are doing instead. Or if I am missing something.
Thank you.
