Skip to content

Instrument (Reactive)AuthorizationManager #11990

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #10964
jzheaux opened this issue Oct 13, 2022 · 2 comments
Closed
Tracked by #10964

Instrument (Reactive)AuthorizationManager #11990

jzheaux opened this issue Oct 13, 2022 · 2 comments
Assignees
Milestone

Comments

@jzheaux
Copy link
Contributor

jzheaux commented Oct 13, 2022

No description provided.

@jzheaux jzheaux mentioned this issue Oct 13, 2022
18 tasks
@jzheaux jzheaux added this to the 6.0.0-RC1 milestone Oct 13, 2022
@jzheaux jzheaux changed the title Time AuthorizationManager Instrument (Reactive)AuthorizationManager Oct 13, 2022
@jzheaux jzheaux self-assigned this Oct 17, 2022
@jzheaux jzheaux moved this to Done in Spring Security Team Oct 24, 2022
jzheaux added a commit that referenced this issue Nov 10, 2022
- If Method Security asks for  too early, it is no longer
eligible for post-processing. As such, this commit defers loading it until
the first authorization request.

Issue gh-11990
@Shabin
Copy link

Shabin commented Oct 23, 2023

When moving from spring 5 to 6 for one of our legacy applications, the change in HttpSecurityBeanDefinitionParser.java which added a ChildAuthenticationManagerFactoryBean factory bean messed up the bean creation order of the application. Since this is a factory bean, it got eagerly initialized during one of a bean postprocessor creation and hence our xml based http security userdetails service bean also got initialized before autowiring postprocessor was created and hence the autowired beans inside in our userdetails resulted in null.

I tried to avoid our custom bean postprocessor which was not required now. But then had another issue from a AbstractBeanFactoryPointcutAdvisor bean which had a StaticMethodMatcherPointcut autowired inside it. Is it not recommended to autowire pointcut inside an advisor? We have lots of similar advisor beans which have autowired pointcut beans.

It will be very difficult for us to change the bean ordering or advisors since it a complicated legacy application. Any option to fall back to the original ProviderManager based security initialization if observability is not required?

@nucleussoftwareopen
Copy link

@jzheaux , I am facing the same problem as mentioned by @Shabin.

jzheaux added a commit to jzheaux/spring-security that referenced this issue Sep 23, 2024
jzheaux added a commit that referenced this issue Sep 26, 2024
jzheaux added a commit that referenced this issue Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants