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:
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
There is a difference in completeness of the claims on the JWT between the users.
this is the problematic JWT:
The one that works has
family_name
and given_name
populated.@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?
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.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#shortcodesJWT Templates | Clerk
Customize your authentication tokens and integrate with anyone!
yeah,
setAuth
returns a promise that resolve once the getToken() function passed in has finished and the token has been sent to Convex@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
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
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?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