Open JonasDoe opened 2 months ago
I wonder if a type ParseError struct{}
would help here.
Although wouldn't you still need to errors.As
and then ignore certain classes of errors?
I'm not sure we want to expose a list of errors, that's not something I've observed in the wild. But the standard solution is to expose an error type.
Hm, a ParseError struct
might be nice b/c it could come with some method receivers which cover that logic:
func (err *ParseError) ToOtherErrThan(jwtErrExeptions ...errror)(remaining error) //result allows run-out-the-mill if err != nil check.
My scenario is, that for example I want skip the validation under certain circumstances. To achieve that, I invoke
jwt.ParseWithClaims(...)
and want to check afterward whether it was the signature check which failed. I understand that I could achieve most of that witherrors.Is(myParsingErr, jwt.ErrTokenSignatureInvalid)
My gripe with that solution is that I'ld implicitly accept other errors wrapped in
myParsingErr
- as long as my one permitted error is amongst those -, and I'm not sure whether this could be exploited, e.g. whenErrTokenInvalidClaims
"hides" an invalid signature.My workaround for now is:
But this is logic must be checked/maintained whenever a new minor version of the jwt library gets released, to ensure all possible errors are covered. Therefore, it would be nice if all possible errors - so basically the array I'm creating myself atm - would be exposed by the library. Or if there was a check for that provided by the jwt library itself.