-
Notifications
You must be signed in to change notification settings - Fork 6.1k
DefaultMethodSecurityExpressionHandler is not eligible for getting processed by all BeanPostProcessors #9845
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
Comments
Thanks, @dodgex, for the report. I agree that this is a continuation of #8407, specifically this comment. Would you be able to submit a PR to add |
Hey @jzheaux I openend #9860 that addes the Unfortunately I have not found a way to handle the I'll try to spend some more time to see if I find a way but I'm not sure if i can. |
Even having a custom The issue seems to be that the I think a possible solution, although possibly a bit ugly, could be merging |
I think this might be addressable by moving the post processing of The default handler is already being further configured in the Also, with this change, applications will be able to register a It appears the post processing was added for #2526, so we should ensure that such a change does not regress that ticket. Can you confirm that moving the post processing to the end of |
I just tested it and the log message does no longer appear. As a result I added a second commit to the PR, it is not yet rebased in case there is more changes necessary. If you want me to squash the commits I'll do that. I would check if that causes a regression for #2526 but I'm not how to that in a way to be sure it is not regressing that without knowing what he had set up in his project what caused the problem. |
Added missing infrastructure role to methodSecurityMetadataSource bean and move the post processing of the defaultMethodExpressionHandler to the end of afterSingletonsInstantiated. Closes spring-projectsgh-9845
Hello! I'm using version 5.5.1 and the following configuration:
I have not overriden MethodSecurityMetadataSource bean in my configuration. And this is what I get into the log:
If I remove
(Message for methodSecurityConfiguration appears) Could you please inform, if is not eligible for getting processed by all BeanPostProcessors is going be fixed for both DefaultMethodSecurityExpressionHandler and methodSecurityMetadataSource? |
Thanks, @kuzmeo, for reaching out. This was fixed in 5.6.0-M1, though I neglected to add the milestone. I've corrected that now. The first GA version that will have the correction is 5.6.0. The warning, in this case, is likely a false positive and the purpose of this ticket was to change the startup arrangement so as to alleviate that confusion. If you are experiencing any issues related to bean post-processing itself, will you please file a separate ticket for that? |
Added missing infrastructure role to methodSecurityMetadataSource bean and move the post processing of the defaultMethodExpressionHandler to the end of afterSingletonsInstantiated. Closes spring-projectsgh-9845
Describe the bug
This is kind of a follow up to #8407. I just found that in my project there are two beans related to Method Security logged that they are not eligible for post processing.
To Reproduce
As this also happens in a fresh project this is kind of easy to reproduce:
@EnableGlobalMethodSecurity(prePostEnabled = true)
to the application classThe issue only seems to occur with spring-web and spring-data-jpa (maybe other combinations too)
Expected behavior
Ideally the message should not be logged.
Additional Info
Adding a custom config extending
GlobalMethodSecurityConfiguration
and overridingmethodSecurityMetadataSource
to add the@Role
annotation allowed me to get rid of the related log message but I found no way to do this for the message related toDefaultMethodSecurityExpressionHandler
.The custom config:
I'm not sure to what extend this is an actual issue as the security seems to work as expected. but as in the original issue #8407 and the #8429 there where attempts to work against these log messages and it is suggested that those INFO logs maybe should be warnings I thought I should mention it.
The text was updated successfully, but these errors were encountered: