Hi, I've recorded this as https://issues.apache.org/jira/browse/RAMPART-400 (patch included)
Regards, Nathan > Date: Mon, 4 Mar 2013 09:43:26 -0500 > Subject: Re: Rampart: sp:HashPassword does not require receiving a hashed > password > From: [email protected] > To: [email protected] > > Hi Nathan, > > On Mon, Mar 4, 2013 at 1:48 AM, Nathan Clement > <[email protected]> wrote: > > Hi Ruchith, > > > > Thanks for your quick response. I was halfway through writing my own patch > > to 1.6.2 in that exact area of the code :) I have instead applied your > > changesets to my working copy of the Rampart source. However, I'm having a > > problem with the following code: > > > > } else if (wssUt.getPassword() == null || > > !wssUt.getPasswordType().equals(WSConstants.PASSWORD_TEXT)) { > > throw new RampartException("invalidUsernameTokenType"); > > > > When a PasswordDigest is used, wssUt.getPassword() returns the hashed > > password value, and so this exception is thrown, even though the request is > > valid according to the policy. Am I missing something here, or should this > > if statement be something like: > > > > } else if (!ut.isHashPassword() && (wssUt.getPassword() == null || > > !wssUt.getPasswordType().equals(WSConstants.PASSWORD_TEXT))) { > > throw new RampartException("invalidUsernameTokenType"); > > > > Happy to raise a bug and provide a patch if you concur. > > Yes. Please a bug and attach a patch. > This condition is intended to cover the case when policy requires a > UsernameToken with a plain text password. > Therefore it needs the additional check to avoid breaking the digest case. > > Thanks, > Ruchith > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
