allen
allen2y ago

Auth not working for some users

I have the same codebase running from two devices for two users and seeing two different sets of behavior and unsure how to resolve. My client does the following:
const createUser = useMutation('users/mutations/createUser');
...
await convexClient.setAuth(async () => getToken({ template: 'convex' }));
await createUser(); //
const createUser = useMutation('users/mutations/createUser');
...
await convexClient.setAuth(async () => getToken({ template: 'convex' }));
await createUser(); //
For one user, everything works as expected. For another, my createUser mutation throws because the request isnt authorized (auth.getUserIdentity() returns null). I have verified that a JWT is returned from getToken. I set a timeout prior to calling the mutation of 1000ms to see if there was a race condition, but that produced the same results. I am unsure how to further debug this or inspect why setAuth doesnt appear to be functioning in this case.
9 Replies
allen
allenOP2y ago
There is a difference in completeness of the claims on the JWT between the users. this is the problematic JWT:
{
"aud": "convex",
"email": null,
"email_verified": false,
"exp": 1680190385,
"externalId": null,
"family_name": null,
"given_name": null,
"iat": 1680190325,
"iss": "https://above-ferret-23.clerk.accounts.dev",
"jti": "xxx",
"nbf": 1680190320,
"picture": "https://www.gravatar.com/avatar?d=mp",
"sub": "user_xxx",
"updated_at": 1680189824
}
{
"aud": "convex",
"email": null,
"email_verified": false,
"exp": 1680190385,
"externalId": null,
"family_name": null,
"given_name": null,
"iat": 1680190325,
"iss": "https://above-ferret-23.clerk.accounts.dev",
"jti": "xxx",
"nbf": 1680190320,
"picture": "https://www.gravatar.com/avatar?d=mp",
"sub": "user_xxx",
"updated_at": 1680189824
}
The one that works has family_name and given_name populated.
ian
ian2y ago
@gautamg am I remembering correctly that null doesn’t match the OpenID standard and is rejected by our rust parsing library currently? Also, I’m curious if you could do the createUser inside an <Authenticated> block to not have the race. I’m not sure if setAuth returns the promise from the first token fetch - @ballingt do you remember?
allen
allenOP2y ago
I still need to refactor to the Clerk auth provider. I'll take a look at that then. However, I've never had an issue with a race condition prior. If the JWT is malformed, I'd assume setAuth should throw, no? Ideally you could coerce the nulls though. Not sure how responsive clerk would be to the change in how they issue tokens, unless the JWT template could be tweaked to deal with this.
allen
allenOP2y ago
I don't see a way to put any conditionals in their template language. They do document that null is the expected type though: https://clerk.com/docs/request-authentication/jwt-templates#shortcodes
JWT Templates | Clerk
Customize your authentication tokens and integrate with anyone!
ballingt
ballingt2y ago
yeah, setAuth returns a promise that resolve once the getToken() function passed in has finished and the token has been sent to Convex
gautamg
gautamg2y ago
@ian re: null -- our library does reject them, but I don't remember offhand if the spec forbids it. @Michal Srb would have the most up to date info
ian
ian2y ago
We’re working with the Clerk team on it. They were considering adding conditionals or we could pre-process the null values out, wasn’t sure which we’re going with but for now sounds like the nulls are the problem @allen
allen
allenOP2y ago
Ok. I'll back out those claims for now May want to note it on the clerk integration docs unless this is going to be a quick turn around Also, thoughts on having getToken bubble that rust error back to the client and reject the promise?
ian
ian2y ago
I agree that sounds like the right behavior - filing a task now I'm not sure if it'll bubble down to the client or if we'd want to fail it in the query / mutation on auth.getUserIdentity

Did you find this page helpful?