This ticket addresses the Servlet implementation of #7699
Comment From: philsttr
@jgrandja Feel free to tag me as a reviewer on the implementation if you want an extra set of eyes.
Comment From: jgrandja
@philsttr I just submitted the PR for the Servlet implementation #7986. I'm planning on merging this by end of next week. If you have time to review that would be great. No worries if you're busy next week.
Comment From: jgrandja
@philsttr I forgot to mention...when I was implementing the Servlet version, I noticed a code path that may not be valid. This specific test throws an OAuth2AuthorizationException directly from the ExchangeFunction, which ultimately branches into this code path. I'm not sure this scenario could happen. Maybe I'm missing something that you are seeing? Could you look at this again and provide some clarification?
Comment From: philsttr
That scenario will not happen by the classes and functionality provided by spring security out-of-the-box.
I specifically added that code path to allow downstream filters to be able to inspect a resource server response and throw an OAuth2AuthorizationException to trigger the logic in the upstream filter function. This could be utilized by applications talking to a non-compliant resource server. For example, maybe their resource server returns a 400 status... or maybe it's an rpc-style server that returns an error in the response body.
Comment From: jgrandja
Gotchya! That makes sense. Ok I will add it back into the Servlet impl.
Comment From: jgrandja
@philsttr There were some package tangles in the Servlet and Reactive implementations. I resolved it via c8cc971. When you get a chance, take a look at the changes and let me know if you have any concerns. Thanks.
Comment From: philsttr
@jgrandja LGTM!