Для аннотаций безопасности Spring с EL требуется скомпилированная отладочная информация?

Я рассматриваю возможность использования аннотаций Spring Security для своего приложения с функцией EL (язык выражений). Например:

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

Мне нужна возможность EL, потому что я создал свою собственную реализацию ACL. Однако, чтобы использовать эту возможность с аргументами типа «#contact», в документации Spring сказано следующее:

Вы можете получить доступ к любому аргументу метода по имени как к переменной выражения, при условии, что ваш код содержит скомпилированную отладочную информацию.

Это вызывает два вопроса:

  1. Допустимо ли иметь производственное приложение, распространяемое на коммерческой основе, с информацией об отладке?
  2. Если нет, то есть ли способ обойти это?

Спасибо за любое руководство по этому поводу!


debugging spring-security acl
person HDave    schedule 25.05.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Я думаю, это не было вариантом, когда вы подошли к проблеме в первый раз, но теперь вы можете это сделать.

@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

person irbian    schedule 28.09.2015

arrow_upward
9
arrow_downward

В качестве обходного пути вы можете реализовать собственный ParameterNameDiscoverer. с вашей собственной стратегией. Вот пример, который создает простые пронумерованные имена (arg0 и т. д.):

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;
    }
}

И конфигурация:

<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>
person axtavt    schedule 25.05.2010
comment
Это отличный материал. Я не знал об этом интерфейсе. Основываясь на этой реализации, я думаю, что я бы ссылался на аргументы по номеру в аннотации: @PreAuthorize(hasPermission(#arg0, 'admin')) Честно говоря, я думаю, что это нормально для моих целей. Как вы относитесь к отладочной информации в распределенных JAR-файлах? - person HDave; 26.05.2010
comment
@HDave: я ничего не могу сказать об отладочной информации в распределенном коде, лично мне не нравятся вещи, зависящие от отладочной информации, потому что это делает поведение кода зависимым от параметров компилятора. - person axtavt; 26.05.2010
comment
Это все еще лучший способ, по состоянию на весеннюю безопасность 3.1, октябрь 2013 г.? - person NimChimpsky; 01.10.2013

arrow_upward
1
arrow_downward

Я не могу найти ссылку сейчас, но вам может быть интересно узнать, что Java 8 всегда будет включать имена параметров, даже если я считаю, что Java 8 будет включать имена параметров всегда, даже в режиме отладки.

person pimlottc    schedule 13.03.2014