Results 1 to 5 of 5

Thread: AOP and acegi security(password maintainance)

  1. #1

    Default 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. #2
    Join Date
    Jul 2007
    Location
    Juan Les Pins, France
    Posts
    42

    Default

    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 at 05:01 AM.

  3. #3

    Default

    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.

  4. #4
    Join Date
    Jul 2007
    Location
    Juan Les Pins, France
    Posts
    42

    Default

    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

  5. #5

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •