-
Notifications
You must be signed in to change notification settings - Fork 6.2k
Description
I recently ran into an issue where I tried to make a custom JwtDecoder that would try to parse the incoming token in order to inspect the headers, before doing further validation. SignedJWT.parse() ended up bubbling up a general ParseException and that resulted in an error thrown and logged without tracing information. It was pointed out that the surface level problem here could be solved by catching all exceptions and rethrowing using a JwtException instead, but this raises a couple issues:
- This is intrinsically an old Java pattern and it will effectively force all implementers of JwtDecoder to always have to implement a general
try/catch(ex: Exception)and rewrap in order to have observable errors and traceable logs, even if you're using Kotlin. - This same issue likely exists within other places called by
FilterChainProxy.doProxy - People calling the application with an invalid token is unlikely to be rare, especially in the case of an attacker, so it seems heavy-handed to raise an exception for this
In my real project, an application gateway bug caused this case to happen a lot and because of the servlet error log raised a higher level than usual alert. However, the problem was harder to track down because of the lack of a trace ID to tie it to other related logs.