I can't speak about the release, as Ben has actually done all of those (and after a spurt of code and suggestion in April, I' ve actually been too busy to do much with Acegi anyways, aside from just using it of course). W/regard to making it "the" security component for Spring, I'm not so sure there's much reason to do that right now, from a technical reason anyways. Because of the whole IOC implemenmtation approach there are no real constraints on what the framework can do as an external addon. From a marketing point of view of course, it might help, but we (the Spring developers) push it as much as possible anyways. The trouble with trying to qualify it as "the" security framework is that almost everybody's needs in this space are different..

Colin

Mark St Godard wrote:




Colin,

Thanks, I will checkout from CVS.

I should have looked at the HEAD as I see the change now  :)

       // Ensure we return the original credentials the user supplied,
       // so subsequent attempts are successful even with encoded
passwords
       return new UsernamePasswordAuthenticationToken(principalToReturn,
           authentication.getCredentials(), user.getAuthorities());

Same change that I did :)

Any idea when you and Ben are doing another release? or when there will be
a final release?
Or if and when Acegi will be integrated as "the" security component for
Spring?

Thanks
Mark



|---------+--------------------------------------------------->
|         |           Colin Sampaleanu <[EMAIL PROTECTED]>    |
|         |           Sent by:                                |
|         |           [EMAIL PROTECTED]|
|         |           ceforge.net                             |
|         |                                                   |
|         |                                                   |
|         |           06/26/2004 09:14 PM                     |
|         |           Please respond to                       |
|         |           acegisecurity-developer                 |
|---------+--------------------------------------------------->
 
>----------------------------------------------------------------------------------------------|
 |                                                                                     
         |
 |       To:       [EMAIL PROTECTED]                                |
 |       cc:                                                                           
         |
 |       Subject:  Re: [Acegisecurity-developer] JdbcDaoImpl + Md5PasswordEncoder +    
         |
 |        DaoAuthentication                                                            
         |
 |                                                                                     
         |
 |                                                                                     
         |
 
>----------------------------------------------------------------------------------------------|



Mark,

You need to be running a CVS version post the last 0.51 official
release. This is a bug that was introduced around the 28th or 29th of
May if I remember, and fixed about the 6th or so of June...

Colin


Mark St Godard wrote:



Hi Ben, Colin et al

Configuring the JdbcDaoImpl and am having problems with the 2nd
authentication attempt:


Config snippet:

<bean id="daoAuthenticationProvider" class=
"net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider">
<property name="authenticationDao"><ref bean="authenticationDao"/></
property>
<property name="userCache"><ref bean="userCache"/></property>
<property name="saltSource"><ref


bean="saltSource"/></property>


          <property name="passwordEncoder"><ref bean="passwordEncoder"
/></property>
    </bean>

    <bean id="passwordEncoder" class=
"net.sf.acegisecurity.providers.encoding.Md5PasswordEncoder">
    </bean>


Problem that occurs is that the first authentication attempt is successful (passwords equal when debugging in Md5PasswordEncoder)

then I notice in the DaoAuthenticationManager the Authentication Token is
created.... like

 return new UsernamePasswordAuthenticationToken(user.getUsername(),
      user.getPassword(), user.getAuthorities());

At this point the  user.getPassword() ... is the MD5-encoded password...

then all further attempts to authenticate... try to encode the already
encoded password   (since Authentication token is cached)


My 2 questions are:

First, am I missing something? Like a configuration setting or otherwise?

Secondly, does the Authentication Token require to store the credentials


from the database or the credentials from the original request?


i.e.  clear text vs. md5 encoded


To get around this and to get it working, I did something like this in


line


197

net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider

method -->  public Authentication authenticate(Authentication
authentication)

// Mark St.Godard - should the encoded or clear text password be placed in
the token?
//  return new UsernamePasswordAuthenticationToken(user.getUsername(),
//  user.getPassword(), user.getAuthorities());
  return new UsernamePasswordAuthenticationToken(user.getUsername(),
        authentication.getCredentials(), user.getAuthorities());


I am sure I am missing something.

Any advise is appreciated.

And yes Ben, I am running on Websphere 5.1  (but that shouldnt matter ....
this is standard Java stuff :)

Thanks in advance,

Mark







-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to