-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Exposing Beans for defaultMethodExpressionHandler can prevent Method Security #4020
Comments
@bitsofinfo Thanks for the report and the sample! I am unable to reproduce (what I understand as) the problem. If I uncomment the autowired and the repository in Application https://github.com/bitsofinfo/spring-boot-pre-authorize-issue-01/blob/d6a23214f1b62183e7e971e7d33d8ce5ac888d58/src/main/java/my/test/Application.java#L37-L38 Then invoke
I still see the following in the logs
From what I can tell everything is working just fine. Can you help me understand what the problem is? Perhaps this is an example of…works for me and not for you? cc @jgrandja |
Thats odd, myself and an associate did the following and it fails everytime as expected.
See the expected entries in STDOUT Stop the process:, edit Application.java and uncomment the noted section.
The expected entries no longer show up. |
When the entries don't show up what happens? Do you get access denied or access permitted? What OS and what JDK (vendor and exact version) are you using? |
PS: You can run the following to get the OS and JDK information I need
|
Thats the point, when those system prints from the
|
This makes sense. I understand you are not getting the desired behavior ( the custom |
Yes I suspect the latter, that the repo is not getting proxied at all. |
Can you provide a System.out.println of @Autowired
public void see(TestRepository test) {
System.out.println("This is my value ====================== " + test);
} |
added to Application.java |
In both instances (commented and uncommented) its this:
|
Thanks! In order to figure out what is triggering this behaviour, can you try On Aug 10, 2016 11:58 AM, "bitsofinfo" notifications@github.com wrote:
|
I'm already tied up w/ another task and can't spend any more time on this today. Feel free to play w/ it however you want, fork or pr, or just locally to experiment with it. I just needed to point this out and document it as I spent about 10 hours yesterday trying to widdle down a very complex app to this to reproduce this maddening result :) To confirm, yes I worked around this by moving that repo bean to another config class. But my point is that this could be a giant time waster for folks, do to the lack of info on the cause. I'm not sure if this simply a chicken-before-the-egg kind of dependency issue w/ the proxying or what. But either way it just silently causes odd behavior that is very hard to pinpoint the cause of (i.e. from the spring user's perspective just trying to wire a bean to use) |
Agreed. This is a workaround, but should not be required. Mostly trying to figure out what is happening so I can fix it (difficult since I cannot reproduce it though). |
One more thing. Are you importing it into an IDE at all or do you only run from the command line? If you do import into an IDE which one? |
So you have run this sample project, and no matter what the state of the @Autowired bean in Application.java, you ALWAYS have the System print from PermissionEvaluator outputting to the console? I am only running this from the cmd line. |
Correct. I always see the print statement from the custom The only difference is that I have a newer version of the JDK. I have also tried with jdk1.8.0_40.jdk and that works for me as well. |
great, so what does that mean, something w/ my local .m2 or gradle repos is messed up? |
Going to have my colleagues run it as well and chime in |
@rwinch I am seeing the same result as @bitsofinfo on my local environment. Essentially when the autowiring is commented my output for multiple
when I uncomment for my initial
And no more output on other Here is my
|
@peloncano Thanks for the response.
I'm not sure what is causing this, but my best guess is to do with ordering of classpath scanning which can at times cause weird issues like this. @jgrandja Can you give the sample a try to see if you can reproduce this? |
@bitsofinfo and @peloncano I just tried it again and I can reproduce the issue. |
I have figured out the issue. The problem is that:
Then in BeanFactoryAdvisorRetrievalHelper the To get around this I think we need to delay looking up any Beans in |
Previously if a Bean for GlobalMethodSecurityConfiguration's defaultMethodExpressionHandler was found on a Configuration that also @Autowired a Bean that enabled method security, the Bean that was @Autowired would not have security enabled. This fixes the issue by delaying the lookup of Beans populated on GlobalMethodSecurityConfiguration's defaultMethodExpressionHandler. Fixes spring-projectsgh-4020
Previously if a Bean for GlobalMethodSecurityConfiguration's defaultMethodExpressionHandler was found on a Configuration that also @Autowired a Bean that enabled method security, the Bean that was @Autowired would not have security enabled. This fixes the issue by delaying the lookup of Beans populated on GlobalMethodSecurityConfiguration's defaultMethodExpressionHandler. Fixes spring-projectsgh-4020
Awesome, great work @rwinch thanks for looking into it! |
Thank you @bitsofinfo and @peloncano for all your help reporting & isolating the issue! |
Closed via #4021 |
@bitsofinfo / @peloncano I wanted to thank you again for all your efforts in helping isolate this issue. Spring Security 4.1.2 is now released with fixes for the issue you were encountering. See https://spring.io/blog/2016/08/12/spring-security-4-1-2-released for the announcement |
No problem glad to help, any thoughts on this one @rwinch? https://github.com/bitsofinfo/spring-boot-cloud-eureka-path-variable-issue |
@bitsofinfo Probably best for the Cloud team to look at. |
Hello, I have found that this issue is back. I assume I should start a new issue since this thread is closed. I am running the following versions: The LendingTransactionPermissionEvaluator is in the same Config as my Repo(s). For most Repos there is no issue. But when I use the Repo of the same entity type that the LendingTransactionPermissionEvaluator acts on... then the LendingTransactionPermissionEvaluator will silently not get invoked and permissions fly as if there was no security. Thanks very much, and I will start a new Post as well. |
Sorry, I meant to post "TargetedPermissionEvaluator" instead of my custom name "LendingTransactionPermissionEvaluator" |
Updated Summary
If a
@Configuration
provides a@Bean
that is used to defaultGlobalMethodSecurityConfiguration's defaultMethodExpressionHandler
sdefaultMethodExpressionHandler
it will prevent any@Bean
that is@Autowired
into the same@Configuration
from having method security enabled. For example:Summary
spring-data-rest
@PreAuthorize
annotated methods on a@RepositoryRestResource
annotatedPagingAndSortingRepository
interface fail to be evaluated on invocation if the resulting repository bean instance is@Autowired
into a@Configuration
annotated class.Actual Behavior
See this project for a runnable example:
https://github.com/bitsofinfo/spring-boot-pre-authorize-issue-01
Expected Behavior
@PreAuthorize expressions should be evaluated on requests that hit the repository
Configuration
See this project for a runnable example:
https://github.com/bitsofinfo/spring-boot-pre-authorize-issue-01
Version
All latest spring-boot components
See this project for a runnable example:
https://github.com/bitsofinfo/spring-boot-pre-authorize-issue-01
Sample
https://github.com/bitsofinfo/spring-boot-pre-authorize-issue-01
The text was updated successfully, but these errors were encountered: