Chris,
In my realm, you're saying that the digest attribute is how the password is
stored in the database? Not how it is entered/translated when the user logs
in.
I'm using this to generate a MD5 hash of the password = password:
java -classpath
C:\apache-tomcat-6.0.24\lib\catalina.jar;C:\apache-tomcat-6.0.24\bin\tomcat-juli.jar
org.apache.catalina.realm.RealmBase -a md5 password
I don't understand why I can't authenticate with what I have.
When I login and supply a username and password, I get the 401 error page.
This user does have the "webservicereader" role. And the user's password is
the same value in the database as in the dos window when I create a password of
password.
Page 144 of the servlet 2.5 spec speaks to the login-config Element. It
doesn't list the values for "realm-name", is DataSourceRealm valid? I've tried
using DIGEST instead of BASIC for the auth-method, but that change doesn't make
a difference, so I must have something else wrong?
The only thing I haven't tried is changing the names of the tables to the names
listed in the Tomcat docs. Maybe I can't use different table names for users
and roles?
I do have SSL enabled and I have another webapp working with Active Directory
authentication - BASIC over HTTPS. This "experiment" is an extension of the
SSL question I posted a few weeks ago. That is probably why the web.xml looks
very similar.
** META-INF/context.xml:
<Context antiJARLocking="true" path="/sample2" privileged="true">
<!-- This Realm uses a DataSourceRealm -->
<Realm className="org.apache.catalina.realm.DataSourceRealm"
dataSourceName="jdbc/SecurityStore"
userTable="SECURITYSTORE_USERS"
userNameCol="USERNAME"
userCredCol="MD5PASSWORD"
userRoleTable="SECURITYSTORE_ROLES"
roleNameCol="ROLENAME"
digest="MD5"/>
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/SecurityStore</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<Resource name="jdbc/SecurityStore"
auth="Container"
type="javax.sql.DataSource"
username="username"
password="password"
driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
url="jdbc:sqlserver://servername;database=databasename"/>
</Context>
** web.xml:
<!-- SECURITY CONSTRAINT -->
<security-constraint>
<web-resource-collection>
<web-resource-name>samplewebapp2</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webservicereader</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<!-- LOGIN CONFIGURATION-->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>DataSourceRealm</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<role-name>webservicereader</role-name>
</security-role>
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, March 24, 2010 12:47 PM
To: Tomcat Users List
Subject: Re: Connecting to a Database
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 3/24/2010 1:28 PM, Leo Donahue - PLANDEVX wrote:
> I know you can specify digest for a Realm, but I don't see where I can
> do that for a Resource.
Note that the digest is for hashing passwords during /user/ authentication, not
connecting to the database.
> Do I need to leave the password of
> "javadude" in the Resource in clear text, or can it be a digested
> version of "javadude" in clear text in the Resource element?
You cannot hash the db password. If you could, how would Tomcat decrypt it to
make the connection?
> The SQL table of user passwords will be in digest, but I wasn't sure
> if I could use a digested password as part of the configuration for
> the account that connects to the "authstore" database.
Nope. Search the archives for that question being asked repeatedly, or just
think about the implications of hashing a password that you want to use later.
Then, think about the implications of /two-way/ encryption for a password and I
think you'll see that you're just moving the problem somewhere else.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuqbDYACgkQ9CaO5/Lv0PBhHwCgqFQcdHypen2gtOfbtqjhd0IR
CNUAoLT3Joi1rTnqvWC0wQ82Hls1zoK9
=uX5k
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
