Announcement Announcement Module
Collapse
No announcement yet.
AOP and acegi security(password maintainance) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • AOP and acegi security(password maintainance)

    Hi,

    I use acegi security's simple daoauthenticationprovider which basically just interface with a dao that returns username/password.

    However, it is not a good idea to store plain text password and acegi does provide encoder which would be run against the user input then compared with the stored(thus must be encoded too) password.

    So the problem becomes, how can I be sure that my stored password is encoded the same way acegi expected.

    This I thought is a perfect example where AOP can solve. I can just intercept either my model class' "setPassword" method or at the dao's save method.

    Code:
    class User {
      ....
      public void setPassword(String password) {
         this.password = password
      }
    }
    
    class GenericDao<T, PK> {
        protected Class<T> modelClass;
    
        /**
         * Constructor that takes in a class to see which type of entity to persist
         * @param modelClass the class type you'd like to persist
         */
        public GenericDao(final Class<T> modelClass) {
            this.modelClass = modelClass;
        } 
        ....
    }
    and the aop config

    Code:
        <aop:config>
            <aop:advisor 
            	id="encodePassword" 
            	advice-ref="setPasswordInterceptor" 
            	pointcut="execution(* org.crank.crud.GenericDao.*(..))"/>
        </aop:config>
    
        <bean id="setPasswordInterceptor" class="org.gng.jbc.advice.EncodePassword">
            <property name="authenticationProvider" ref="daoAuthenticationProvider"/>
        </bean>
    However, the problem of this approach seems to be that :

    1. There actually is no bean created for the models and spring's AOP facilities only works on beans that is created through it. Thus I cannot intercept at the model level.

    2. My generic dao beans are created through the ProxyBeanFactory which again seems to be completely bypass the AOP interception(not sure why though).

    I did verify that if instead of using the generic DAO approach but create a wrapper class and create a bean using that wrapper class(where I inject my generic dao bean into it), I can intercept my wrapper class.

    any advice or pointers ?

  • #2
    Does your EncodePassword advice implement BeforeAdvice?

    Just as a side note, I would use the order attrbiute on the aop:advisor tag to control the order in which the proxies will get invoked.

    Creating advices by implementing specific interfaces like BeforeAdvice is a spring 1.x approach, works well with the ProxyFactoryBean style of aop configuration.

    An alternative to the 1.x style interceptor is to use the aop:aspect tag within the aop:config. Refer to the logging example provided in Mark Fisher's Blog

    Refer to this post for a similar discussion.

    Hope that helps.

    -Nikhil
    Last edited by nikhil78; Jan 14th, 2008, 06:01 AM.

    Comment


    • #3
      yes it does. In fact, I can see it being invoked if I "advice" it on a regular bean created with my desired Interface. But nothing happens when I specify the genericDao interface.

      thanks for the help anyway, keep on searching.

      Comment


      • #4
        Your pointcut expression points to a class and not an interface; which means that class based proxies must be created. The current aop:config creates interface based proxies which is why the advice works when you test it with your desired interface.

        To force using class based proxy, set proxy-target-class="true" on the aop:config tag.

        Code:
        <aop:config proxy-target-class="true" />
        This will create class based proxies.

        -Nikhil

        Comment


        • #5
          thanks for the help.

          my problem is not about class vs interface though.

          I have to admitted that I short cut a little and simplify the problem in the example. I am actually integrating acegi into this http://code.google.com/p/krank/.

          krank use the new javaconfig for bean creation rather than XML. A direct consequence of it is that it actually create a lot less beans and use the plain old 'new'.

          This I believe means that anything which is not a bean created in spring sense would not be subjected to the AOP magics too(as far as I can tell).

          Well, seems that I have to go to the full blown asjectJ to have my desired feature.

          Comment

          Working...
          X