> -----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.
