Skip to content

[Enhancement] Exception Hierarchy in Spring Security #18301

@Jyosua

Description

@Jyosua

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:

  1. 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.
  2. This same issue likely exists within other places called by FilterChainProxy.doProxy
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions