-
Notifications
You must be signed in to change notification settings - Fork 347
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
Comparison of token parsing errors #143
Comments
UPD if err.(*jwt.ValidationError).Errors&jwt.ValidationErrorExpired != 0 && err.(*jwt.ValidationError).Errors&jwt.ValidationErrorSignatureInvalid == 0 It seems to work! |
We implemented go 1.13 error style checking a while ago, you can see in the example how it works Lines 97 to 117 in 6de17d3
|
I wonder if we can capture this in a README, or publish lightweight docs capturing the various use-cases and types of errors. |
我也遇到了该问题,目前依然无法实现过期判断 |
If you remove some characters from the end of the token string, e.g. var tokenString = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJmb28iOiJiYXIiLCJleHAiOjE1MDAwLCJpc3MiOiJ0ZXN0In0.HE7fK0xOQwFEr4WDgRWj4teRPZ6i3GLwD5YC" you still get the message "Timing is everything", which on one side is correct, because the token is still expired. But the more critical problem now is IMO the invalid signature. This probably happens because claim validation is done first, followed by the signature check, which only |
Ah, I get your point now. We could / should adjust the example to the following then:
This is a basic problem of checking multiple wrapped errors. Maybe even the else/if construct is not the best, but it's basically just there to demonstrate the different errors. In a real application I highly suggest aborting whatever you are doing once you encounter any kind of error from
Sort of; the issue is that we want to keep all the errors and not really have a hierarchy of errors, e.g. one that overrides all of them. One could however argue that if we encounter either a malformed token or an invalid signature we basically skip setting the rest of the errors. |
This PR adjusts the error checking example so that a check for an invalid signature is also included. See discussion in #143
Fixed by #234 |
This PR adjusts the error checking example so that a check for an invalid signature is also included. See discussion in #143
This PR adjusts the error checking example so that a check for an invalid signature is also included. See discussion in #143
This PR adjusts the error checking example so that a check for an invalid signature is also included. See discussion in golang-jwt#143
My parsing of token:
I took an example of how to distinguish between errors from the documentation
And here's what I noticed. This patch can fire even when the error is not a token expiration error.
For example, this condition will work even on the "signature is invalid" error.
But only if the token has expired and it has been changed.
In other words:
But the condition should not work on an error like "signature is invalid"?
P.S
Can I compare errors like this?
The text was updated successfully, but these errors were encountered: