-
Notifications
You must be signed in to change notification settings - Fork 6k
WebSecurityConfiguration should autowire PermissionEvaluator the same way GlobalMethodSecurityConfiguration does #4077
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 for creating the issue! Would you be interested in submitting a PR? |
@rwinch PR submitted. Thanks in advance for working with me on this issue. |
I've updated the PR to include testing. Note that I've followed the style/approach of #4020 |
@candrews Thanks! |
Implementations of AbstractSecurityExpressionHandler (such as the very commonly used DefaultWebSecurityExpressionHandler) get PermissionEvaluator and RoleHierarchy from the application context (if the application context is provided, and exactly one of such a bean exists in it). This approach matches that used in GlobalMethodSecurityConfiguration, making everything in Spring Security work the same way (including WebSecurity). Issue spring-projectsgh-4077
Implementations of AbstractSecurityExpressionHandler (such as the very commonly used DefaultWebSecurityExpressionHandler) get PermissionEvaluator and RoleHierarchy from the application context (if the application context is provided, and exactly one of such a bean exists in it). This approach matches that used in GlobalMethodSecurityConfiguration, making everything in Spring Security work the same way (including WebSecurity). Issue gh-4077
Implementations of AbstractSecurityExpressionHandler (such as the very commonly used DefaultWebSecurityExpressionHandler) get PermissionEvaluator and RoleHierarchy from the application context (if the application context is provided, and exactly one of such a bean exists in it). This approach matches that used in GlobalMethodSecurityConfiguration, making everything in Spring Security work the same way (including WebSecurity). Issue gh-4077
Implementations of AbstractSecurityExpressionHandler (such as the very commonly used DefaultWebSecurityExpressionHandler) get PermissionEvaluator and RoleHierarchy from the application context (if the application context is provided, and exactly one of such a bean exists in it). This approach matches that used in GlobalMethodSecurityConfiguration, making everything in Spring Security work the same way (including WebSecurity). Issue spring-projectsgh-4077
The polish broke one of the use cases. Using thymeleaf spring security extras, you can conditionally show elements like this: The DefaultWebSecurityExpressionHandler that ends up being used, with your polish, has a type of |
@candrews This issue is closed. Can you please create a new ticket with details of the issue you are experiencing? |
I was thinking this issue should be reopened, as the reported issue was not fixed. :-) |
Thanks for creating the new ticket. I can understand why you might have thought that reopening this was what needed to be done. To clarify...Once a ticket is associated with a release and that release is performed we do not reopen the issue because the change log is considered immutable at that point. Instead we create a new ticket. Thanks again! |
GlobalMethodSecurityConfiguration
autowiresPermissionEvaluator
from the context:https://github.com/spring-projects/spring-security/blob/4.1.3.RELEASE/config/src/main/java/org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.java#L154
WebSecurityConfiguration
should do the same thing.Currently, it's surprising that when a
PermissionEvaluator
is set up, it just works (with no configuration other than declaring thePermissionEvaluator
bean) when used from Java annotations but the same expression always returns denied (as that's what the default configuration does) when used from in a web context (such as in a JSP sec: expression).The text was updated successfully, but these errors were encountered: