2010-05-25 13 views
6

J'envisage d'utiliser les annotations Spring Security pour mon application, avec la fonction EL (langage d'expression). Par exemple:Annotations de sécurité Spring avec EL - nécessite la compilation des informations de débogage?

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

J'ai besoin de la capacité EL parce que j'ai construit ma propre implémentation d'ACL. Toutefois, pour utiliser cette fonctionnalité avec les arguments de type « #contact », la documentation de printemps dit ceci:

Vous pouvez accéder à toute la méthode arguments par nom expression les variables, à condition que votre code a des informations de débogage dans compilé

Cela soulève deux questions:.

  1. Il est acceptable d'avoir une application de production commercialement distribué avec des informations de débogage en elle?
  2. Si ce n'est pas le cas, y a-t-il un moyen de contourner le ?

Merci pour toute indication à ce sujet!

Répondre

9

Pour contourner ce problème, vous pouvez implémenter un ParameterNameDiscoverer personnalisé avec votre propre stratégie. Voici un exemple qui produit des noms simples numérotés (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; 
    } 
} 

et 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> 
+0

Ce sont d'excellentes choses. Je ne savais pas à propos de cette interface. Sur la base de cette implémentation, je suppose que je ferais référence aux arguments par numéro dans l'annotation: @PreAuthorize ("hasPermission (# arg0, 'admin')") Pour être honnête - je pense que c'est bien pour mes fins . Comment vous sentez-vous à propos des informations de débogage dans les fichiers JAR distribués? – HDave

+2

@HDave: Je ne peux rien dire à propos des informations de débogage dans le code distribué, personnellement, je n'aime pas les choses dépendant du débogage car cela rend le comportement du code dépendant des options du compilateur. – axtavt

+0

Est-ce encore le meilleur moyen, à partir du printemps, la secrétabilité 3.1, octobre 2013? – NimChimpsky

0

Je ne trouve pas la référence maintenant, mais vous pourriez être intéressés de savoir que Java 8 inclura des noms de paramètres à tout moment, même si je crois que Java 8 inclura des noms de paramètres à tout moment, même en mode debug.