See this discussion http://s.apache.org/gW
On 5/16/13 12:53 AM, "Kishan Kavala" <kishan.kav...@citrix.com> wrote: > > >> -----Original Message----- >> From: Prasanna Santhanam [mailto:t...@apache.org] >> Sent: Thursday, 16 May 2013 12:39 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [ACS41] Current blocker status >> >> On Thu, May 16, 2013 at 11:51:06AM +0530, Prasanna Santhanam wrote: >> > On Wed, May 15, 2013 at 03:07:41PM -0700, Animesh Chaturvedi wrote: >> > > > CLOUDSTACK-2516 >> > > > Create User API compability broken now >> > > > >> > > > Nobody has taken this on yet. >> > > [Animesh>] I will update the JIRA ticket, looks like this was >> > > changed by Kishan to use clear text password. I think functionality >> > > wise it will still work but will cause double encryption. We will >> > > have to wait for Kishan to respond on this. >> > >> > I think Kishan only added regions support. That piece of code has >> > existed for a long time. I'm guessing something in the order of >> > authenticators is going wrong although componentContext.xml.in is >> > using MD5 auth first. Investigating .. >> > >> >> This change happened when the authenticators were moved in to use >> adapters. That change was a logical one to support multiple Auth >> mechanisms. Hugo made the change in (bd58cecc) and it is the right way >>to >> do it. >> >> Prior to Hugo's fix the MD5 authenticator,although called so, would >>only do a >> plaintext match of passwords with the database. Also the >> createUser() would simply persist the password coming in over with wire >>into >> the db. Thereby it assumed tht the passwd would be pre-encoded as MD5 >>at >> the client. >> >> So, why did MD5 passwds get into the DB at all? >> The API documentation asks that the client send in a md5 hashed password >> and our ui script (account.js, sharedFunction.js) is hashing the >>passwords into >> md5. >> >> There was probably a reason behind this. I'm not sure: Here's the >>comment >> indicating the change: >> >> """ >> // Will: The MD5Authenticator is now a straight pass-through comparison >>of >> the // the passwords because we will not assume that the password passed >> in has // already been MD5 hashed. I am keeping the above code in case >>this >> requirement changes // or people need examples of how to MD5 hash >> passwords in java. >> if (!user.getPassword().equals(password)) { >> return false >> """ >> >> After Hugo's fix the MD5 Authenticator (the default authenticator) now >> _actually_ does the encoding and not depend on the client. But the UI >>code >> still seems to exist and double encodes the md5 entry in the form. >> >> So the fix should be >> - UI removes the double hashing when account creation happens. >> - Fix the API doc to ask user to send in plaintext password and allow >> to act based on authenticator configured in componentsContext.xml >> >> As an aside: >> Hugo, the SHA256 authenticator you introduced seems to have been >> removed from the componentContexts. Do you want to include it back, >> commented? >> >> Thanks, >> -- >> Prasanna., >> >> ------------------------ >> Powered by BigRock.com > >Agree with Prasanna. Authenticator changes were introduced via commit >bd58cecc prior to Regions related changes. > >Couple of ways to fix this now: > 1. UI/client sends plain text as suggested by Prasanna along with api >doc fix. This would mean breaking backward compatibility but it's the >clean way. > 2. Other option is to add PlainTextAuthenticator in ComponentContext to >support existing clients. Master already has these changes. > >
