Spring security annotations with EL -- requires debug information compiled in?
Asked Answered
C

3

6

I am considering using Spring Security annotations for my application, with the EL (expression language) feature. For example:

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(Contact contact, Sid recipient, Permission permission);

I need the EL capability because I have built my own ACL implementation. However, to use this capability with the "#contact" type arguments, the Spring documentation says this:

You can access any of the method arguments by name as expression variables, provided your code has debug information compiled in.

This begs two questions:

  1. It is acceptable to have a production application commercially distributed with debug info in it?
  2. If not, is there any way around this?

Thanks for any guidance on this!

Chariot answered 25/5, 2010 at 14:37 Comment(0)
M
2

I guess this wasn´t an option when you approached the problem the first time, but now you can do this

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(@P("contact") Contact contact, Sid recipient, Permission permission);

http://docs.spring.io/spring-security/site/docs/current/reference/html/el-access.html#access-control-using-preauthorize-and-postauthorize

Montagu answered 28/9, 2015 at 7:20 Comment(0)
M
9

As a workaround you can implement a custom ParameterNameDiscoverer with your own strategy. Here is an example which produces simple numbered names (arg0, etc):

public class SimpleParameterNameDiscoverer implements
        ParameterNameDiscoverer {

    public String[] getParameterNames(Method m) {
        return  getParameterNames(m.getParameterTypes().length);        
    }

    public String[] getParameterNames(Constructor c) {
        return getParameterNames(c.getParameterTypes().length);        
    }

    protected String[] getParameterNames(int length) {
        String[] names = new String[length];

        for (int i = 0; i < length; i++)
            names[i] = "arg" + i;

        return names;
    }
}

And configuration:

<global-method-security ...>
    <expression-handler ref = "methodSecurityExpressionHandler" />
</global-method-security>

<beans:bean id = "methodSecurityExpressionHandler" 
    class = "org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler">
    <beans:property name = "parameterNameDiscoverer">
        <beans:bean class = "foo.bar.SimpleParameterNameDiscoverer" />
    </beans:property>
</beans:bean>
Measurable answered 25/5, 2010 at 15:10 Comment(3)
This is great stuff. I did not know about this interface. Based on this implementation I guess I would refer to the arguments by number in the annotation: @PreAuthorize("hasPermission(#arg0, 'admin')") To be honest -- I think this is fine for my purposes. How do you feel about have debug info in distributed JARs?Chariot
@HDave: I can't say anything about debug info in distributed code, personally, I dislike debug-info-dependent things because it makes behaviour of the code dependent on compiler options.Measurable
Is this still the best way, as of spring secruity 3.1, october 2013 ?Brod
M
2

I guess this wasn´t an option when you approached the problem the first time, but now you can do this

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(@P("contact") Contact contact, Sid recipient, Permission permission);

http://docs.spring.io/spring-security/site/docs/current/reference/html/el-access.html#access-control-using-preauthorize-and-postauthorize

Montagu answered 28/9, 2015 at 7:20 Comment(0)
L
1

I can't find the reference now, but you might be interested to know that Java 8 will include parameter names at all times, even when I believe Java 8 will include parameter names at all times, even in debug mode.

Longlegged answered 13/3, 2014 at 0:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.