ReactiveAuthorizationManager + Reactive Method Security #9401
Comments
This was referenced Feb 2, 2021
|
@jzheaux I can take this. |
|
Great, @evgeniycheban! It's yours. I'd recommend waiting until #9630 is merged before proceeding. |
rwinch
changed the title
|
@evgeniycheban Thanks for volunteering to work on this issue. I've updated the description to include more detailed requirements. I think you can start on this issue before we merge the mentioned PR, but base it off the branch with gh-9630 |
|
What is the status of this ticket? |
Waiting for review. |
This was referenced Jun 7, 2022
evgeniycheban
added a commit
to evgeniycheban/spring-security
that referenced
this issue
Aug 16, 2022
jzheaux
added a commit
that referenced
this issue
Aug 25, 2022
jzheaux
added a commit
that referenced
this issue
Aug 25, 2022
- Changed annotation property to useAuthorizationManager to match related XML support - Moved support found in bean post-processors back into interceptors directly. This reduces the number of components to maintain and simplifies ongoing support - Added @deprecated annotation to indicate that applications should use AuthorizationManagerBeforeReactiveMethodInterceptor and AuthorizationManagerAfterReactiveMethodInterceptor instead. While true that the new support does not support coroutines, the existing coroutine support is problematic since it cannot be reliably paired with other method interceptors - Moved expression handler configuration to the constructors - Constrain all method security interceptors to require publisher types - Use ReactiveAdapter to check for single-value types as well Issue gh-9401 Polish
jzheaux
added a commit
that referenced
this issue
Aug 25, 2022
|
In the docs it says that adding Kotlin coroutines support for the reactive method security is blocked by spring-projects/spring-framework#22462, which seems to be done now, so are there any new tickets to follow for the development of this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should provide an implementation of Reactive Method Security that leverages
ReactiveAuthorizationManagersimilar to gh-9289 The implementation should support:Mono<Boolean>Mono<Authentication>Mono<Authentication>if it was not used (i.e. ifpermitAllwas used there is no need to resolve theAuthentication)For full support this may require updates to SpEL support to support Reactor (i.e. it likely needs to support lambdas) but beans can easily return reactive types that would be supported by SpEL.
Related to #9289, #5249, and #4841
Once #9289 is addressed, we could consider applying the same model to reactive method security.
The text was updated successfully, but these errors were encountered: