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

Already on GitHub? Sign in to your account

SEC-1768: Using the "*" wildcard in intercept-method does not include implemented interfaces #2001

spring-issuemaster opened this Issue Jun 17, 2011 · 1 comment


None yet
1 participant

Greg Nieman (Migrated from SEC-1768) said:

Created on behalf of client, with the following use case:

  1. Bean is secured via the intercept-methods tag.
  2. The method attributed of the protect tag is set to "*"
  3. Bean implements an interface and is annotated with @transactional.
  4. None of the methods on the interface are protected unless the interface is explicitly defined in the method attribute.

In this case only the methods on the bean, not the interface are secured when the method is "". They feel that in addition to the methods declared on the bean, all implemented interface methods should also be secured when the "" is specified for the method.

Attached is a sample test case illustrating the behavior.

Luke Taylor said:

The problem here is essentially that two types of Spring AOP proxying are being used - the traditional ProxyFactoryBean approach (which intercept-methods uses) and the auto-proxying approach used by tx:annotation-driven. It's generally a good idea to stick to one or the other, rather than mixing them, otherwise you can end up with two proxies for the same target bean.

I've added a fix to AbstractMethodSecurityMetadataSource to use AopProxyUtils.ultimateTargetClass to test for the case where the security interceptor has been applied to a proxy when it is identifying the target class of the invocation. A better solution might be to use as an alternative:

    <sec:protect-pointcut expression='execution(* com.bsb.incubator.interceptor.*.*(..))' access='ROLE_USER'/>

as this will result in a single proxy being used, which is more compatible with the <aop:config /> approach..

@spring-issuemaster spring-issuemaster added this to the 3.1.0.RC3 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment