Checking again, the method you mention did not work for me because it
is calling the PasswordDigest method that specifies the username and
password but not the realm, so it was using the default realm ->
getting a different encription. I tried providing an empty realm but
that just reverted to the default.
However looking at the code, it seems that in order to be able to use
the method with an empty realm, one needs to specify a realm but use
"none" as name. So if you pass no value, you get a default but if you
pass a value, you can make it use null... a bit convoluted, I would
So one could use your class and specify "none" as realm or use mine,
both should work. I tested it on 3.1.1
Mattias Jiderhamn <[EMAIL PROTECTED]> ha escrito:
> Daniel Lopez wrote (2007-10-29 18:19):
>> I'd like to confirm that this strategy works (with a tiny detail I
>> will explain) and I have now an application that is able to
>> authenticate through the container in Resin and Tomcat.
>> The only detail I had to modify is that wherever it reads:
>> return super.getPasswordDigest(...
>> it should read
>> return super.getPasswordDigest().getPasswordDigest(...
>> The reason being that the class that really performs the encrypting is
>> not the authenticator itself but a utility class called PasswordDigest
>> that can be accessed through getPasswordDigest().
> Just for the record: The
> com.caucho.server.security.AbstractAuthenticator has an overloaded
> getPasswordDigest() that does just that:
> public String getPasswordDigest(HttpServletRequest request,
> HttpServletResponse response,
> ServletContext app,
> String user, String password)
> throws ServletException
> if (_passwordDigest != null)
> return _passwordDigest.getPasswordDigest(request, response, app,
> user, password);
> return password;
> So I still claim the code below is sufficient (at least for Resin 3.0).
> Anyway, glad I could help.
resin-interest mailing list