I'm interested in more control over hapi-auth-jwt2's error-handling behavior. Specifically:
I'd like to log error details if JWT validation fails. (See #298.) For example, if a token has expired, I could log the token's subject (username) to investigate why that user's token didn't get properly renewed.
I'm interested in allowing multiple JWT schemes. (See #277, #217.) I can do this now by using a custom errorFunc to clear message (see here); however, it would be nice to have more control. For example, if I had access to the jsonwebtoken error, then I could check whether validation failed because of an unknown issuer (in which case I'd clear message and let Hapi try its next scheme) or an expired token or invalid audience (in which case I know the token is invalid - no sense continuing).
I realize I could provide a custom verify function to do all of this, but it seems like it may be worth adding additional information to errorFunc to give it more context so it can do this itself. (It seems to fit logically there, and others have requested similar functionality, and overriding verify adds complexity and the possibility of security-sensitive bugs.) Specifically:
The verify_err thrown by verifyJwt, if available
The decoded token, if available
Rather than adding extra parameters to errorFunc, it makes sense to me to add these within the ErrorContext parameter.
I'm interested in more control over hapi-auth-jwt2's error-handling behavior. Specifically:
message(see here); however, it would be nice to have more control. For example, if I had access to the jsonwebtoken error, then I could check whether validation failed because of an unknown issuer (in which case I'd clearmessageand let Hapi try its next scheme) or an expired token or invalid audience (in which case I know the token is invalid - no sense continuing).I realize I could provide a custom
verifyfunction to do all of this, but it seems like it may be worth adding additional information toerrorFuncto give it more context so it can do this itself. (It seems to fit logically there, and others have requested similar functionality, and overridingverifyadds complexity and the possibility of security-sensitive bugs.) Specifically:verify_errthrown byverifyJwt, if availabledecodedtoken, if availableRather than adding extra parameters to errorFunc, it makes sense to me to add these within the ErrorContext parameter.