Re: [Resin-interest] Resin/Tomcat Common Authenticator [SOLVED]
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);
else
return password;
}
So I still claim the code below is sufficient (at least for Resin 3.0).
Anyway, glad I could help.
/Mattias
...
...
public class MyJdbcAuthenticator extends JdbcAuthenticator {
public MyJdbcAuthenticator() {
super.setPasswordDigestRealm(null);
}
public String getPasswordDigest(HttpServletRequest request,
HttpServletResponse response, ServletContext app, String user, String
password) throws ServletException {
return super.getPasswordDigest(request, response, app, null, password);
}
public String getPasswordDigest(String password) throws ServletException {
return super.getPasswordDigest(null, null, null, null, password);
}
}
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin/Tomcat Common Authenticator [SOLVED]
Hi Mattias,
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
say :).
So one could use your class and specify none as realm or use mine,
both should work. I tested it on 3.1.1
Thx.
S!
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);
else
return password;
}
So I still claim the code below is sufficient (at least for Resin 3.0).
Anyway, glad I could help.
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin/Tomcat Common Authenticator [SOLVED]
Hi,
It took me a while because I was busy with other things but for the
benefit of future generations, 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(). The weird choice
of names in this case (methods and class names equal) is surely
going to confuse people, as it did to me at the beginning.
Thanks again, Mattias.
D.
S'està citant Daniel López [EMAIL PROTECTED]:
Thanks Mattias,
I had thought about the subclassing option, but I had to try to see if
there was some configuration option I had missed :). In any case, that
will work fine, I believe. I'll be out of town for a week but when I go
back I'll give it a go and let you know how it worked.
Thanks again,
D.
Mattias Jiderhamn escribió:
You could probably implement your own authenticator, possibly just
subclassing the JdbcAuthenticator (see below), then use that
authenticator in resin-web.xml.
I myself wrote a patch for a Tomcat only webapp, that contains this
plus dummy implementations of Tomcat classes/interfaces like
org.apache.catalina.Container, Engine, Host, Realm, Server.
Maybe this code suites your needs too:
public class MyJdbcAuthenticator extends JdbcAuthenticator {
public MyJdbcAuthenticator() {
super.setPasswordDigestRealm(null);
}
public String getPasswordDigest(HttpServletRequest request,
HttpServletResponse response, ServletContext app, String user, String
password) throws ServletException {
return super.getPasswordDigest(request, response, app, null, password);
}
public String getPasswordDigest(String password) throws ServletException {
return super.getPasswordDigest(null, null, null, null, password);
}
}
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin/Tomcat Common Authenticator
Thanks Mattias,
I had thought about the subclassing option, but I had to try to see if
there was some configuration option I had missed :). In any case, that
will work fine, I believe. I'll be out of town for a week but when I go
back I'll give it a go and let you know how it worked.
Thanks again,
D.
Mattias Jiderhamn escribió:
You could probably implement your own authenticator, possibly just
subclassing the JdbcAuthenticator (see below), then use that
authenticator in resin-web.xml.
I myself wrote a patch for a Tomcat only webapp, that contains this
plus dummy implementations of Tomcat classes/interfaces like
org.apache.catalina.Container, Engine, Host, Realm, Server.
Maybe this code suites your needs too:
public class MyJdbcAuthenticator extends JdbcAuthenticator {
public MyJdbcAuthenticator() {
super.setPasswordDigestRealm(null);
}
public String getPasswordDigest(HttpServletRequest request,
HttpServletResponse response, ServletContext app, String user, String
password) throws ServletException {
return super.getPasswordDigest(request, response, app, null, password);
}
public String getPasswordDigest(String password) throws ServletException {
return super.getPasswordDigest(null, null, null, null, password);
}
}
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin/Tomcat Common Authenticator
Hi all, Long story short: I started consulting in a company that is developing a product using Tomcat. They want to be able to run the application in different containers to make sure they are spec compliant and all, so I suggested Resin as an alternative. I've been able to configure the datasources, massage the web.xml to be more compliant etc. but now I came across a problem I'm not sure how easy it is to solve: the authenticator. Both containers have an implementation of a typical jdbc authenticator... but for a tiny detail: Resin uses username+realm+password for the digest and Tomcat uses just the password, hence the digests do not match and all password are considered wrong in one of the containers. The passwords in use are already stored like that and changing them would not really solve the problem but move it to the Tomcat side. I don't use container based authentication in my own applications for this very reason, but they are using it and I thought that might not be an uncommon problem so... is there any way to configure com.caucho.server.security.JdbcAuthenticator to use just the password for the digests? Cheers! D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin/Tomcat Common Authenticator
You could probably implement your own authenticator, possibly just
subclassing the JdbcAuthenticator (see below), then use that
authenticator in resin-web.xml.
I myself wrote a patch for a Tomcat only webapp, that contains this
plus dummy implementations of Tomcat classes/interfaces like
org.apache.catalina.Container, Engine, Host, Realm, Server.
Maybe this code suites your needs too:
public class MyJdbcAuthenticator extends JdbcAuthenticator {
public MyJdbcAuthenticator() {
super.setPasswordDigestRealm(null);
}
public String getPasswordDigest(HttpServletRequest request,
HttpServletResponse response, ServletContext app, String user, String
password) throws ServletException {
return super.getPasswordDigest(request, response, app, null, password);
}
public String getPasswordDigest(String password) throws ServletException {
return super.getPasswordDigest(null, null, null, null, password);
}
}
/Mattias
Daniel Lopez wrote:
Hi all,
Long story short: I started consulting in a company that is developing
a product using Tomcat. They want to be able to run the application in
different containers to make sure they are spec compliant and all, so
I suggested Resin as an alternative.
I've been able to configure the datasources, massage the web.xml to be
more compliant etc. but now I came across a problem I'm not sure how
easy it is to solve: the authenticator.
Both containers have an implementation of a typical jdbc
authenticator... but for a tiny detail: Resin uses
username+realm+password for the digest and Tomcat uses just the
password, hence the digests do not match and all password are
considered wrong in one of the containers.
The passwords in use are already stored like that and changing them
would not really solve the problem but move it to the Tomcat side.
I don't use container based authentication in my own applications for
this very reason, but they are using it and I thought that might not
be an uncommon problem so... is there any way to configure
com.caucho.server.security.JdbcAuthenticator to use just the password
for the digests?
Cheers!
D.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
