-
-
Notifications
You must be signed in to change notification settings - Fork 163
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
jwt.ParseRequest(...) seems to destroy error-wrapping stack #1175
Comments
Ah, this is one of those "when you can have multiple error returns from a single function, how do you present it to the caller" type of situations. (talking aloud) |
@mdjarv Please try the branch in gh-1175 . Should be fixed. |
Thank you, It took longer to wait for my token to expire so I could test it than it took for you to read my issue and provide a fix, incredible work, thank you! |
@mdjarv Cool ! :D I'll merge, but please note that I usually wait for a few days before making releases. For the time being, please use the commit ID after I merge the PR |
Yep, no rush on my part, and |
Describe the bug
When using
jwt.ParseRequest(...)
on a token that fails validation the resulting error can not be checked usingerrors.Is()
becauseParseRequest
is not wrapping the validation errors.This means that you can not check for specific validation failures in a reliable way using
errors.Is
.To Reproduce / Expected behavior
Parsing a request with an expired token above will not return "token expired".
The other
Parse*
functions I've tried work as expected so I can work around this by usingjwt.ParseHeader(...)
instead to make the example above work, however if keeping the error stack is possible forjwt.ParseRequest
while also returning a well crafted error message I think that would be preferable as it will behave consistently with the other parse methods.The text was updated successfully, but these errors were encountered: