-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fail faster in checkTokens
#17
Conversation
679b7cf
to
fab7a3a
Compare
Edit: blegh, I haven't been able to find a way to parse the token expiry. I thought I'd done this in the past, the same way you can with a JWT, but Im not finding satisfaction this time. I stand by this change, but interestingly we may also be able to parse the token to check its expiry, so we can fail even faster w/o a network request. We'd still want to verify via network, but if we can fail even faster on good confidence the network request won't work bc token expiration, then that's awesome. |
} | ||
|
||
}) | ||
)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, missing ;
🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed manually
Requested changes have been made! The token parsing to check expiry locally isn't possible rn from what I have seen. |
underlying file was deleted, logic is largely the same but closing since I don't plan to update this PR |
Currently the code to check tokens will return
false
if any of the tokens we detect fail the network request.But we are still doing sequential network calls to check that.
This PR goes full fail fast via
Promise.all
and returns false if we rejectIs it faster? For most people, prolly not
¯\_(ツ)_/¯
but if a user has several tokens (like I do) but only the last of 10 is bad, it should give us a faster result.