>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >
> > I have set up a JDBCRealm and am using it with form-based login to
> > secure/protect my webapp.  However, I have a few questions which I
> > hope somebody could help me with,
> >
> > 1. The JDBCRealm is set up with the following in server.xml.
> >
> >     <Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"
> >      driverName="org.gjt.mm.mysql.Driver"
> >      connectionURL="jdbc:mysql://localhost/authentication"
> >      userTable="users" userNameCol="user_name" userCredCol="user_pass"
> >      userRoleTable="user_roles" roleNameCol="role_name"/>
> >
> >     However, I have noticed that this requires the password (stored in
> >     the user_pass column) to be clear text, which I really don't like 
>doing.
> >     Is there any way to have store the passwords as hashes (ie. using 
>the
> >     password() function in MySQL) ?
> >
>
>The database password isn't the only sensitive piece of information in
>server.xml -- you should ensure that the server.xml file as a whole is not
>accessible to any OS user other than the one running Tomcat.  In addition,
>you can use security manager protections to prevent webapps from being
>able to access it directly.

Sorry, I was not very coherent in my explanation.
I was worried about storing users' passwords in clear text in the database.
Somebody else has kindly pointed out that JDBCRealm supports hashed 
passwords
in the user/password columns.


> > 2. I read that "a call to j_security_check will be made by every attempt
> >    access your secured pages".  Since I am protecting every page in my
> >    webapp, I'm wondering how efficient is "j_security_check" ?
> >    Does it simply look at the session, or does it make a database call 
>on
> >    each and every request ?
> >
>
>If you are using sessions, the user identity is cached the first time, so
>the database will only get hit once.

Excellent.


> > 3. How do you specify a page for authenticated users who do not have
> >    the correct permissions/roles ?  At the moment, I have this in 
>web.xml,
> >
> >     <login-config>
> >         <auth-method>FORM</auth-method>
> >         <form-login-config>
> >             <form-login-page>login.jsp</form-login-page>
> >        <form-error-page>login-error.jsp</form-error-page>
> >     </form-login-config>
> >     </login-config>
> >
> >     login.jsp is the form that shows when an authenticated user tries to
> > access the site.
> >     login-error.jsp is displayed when an incorrect username/password is
> > submitted.
> >
> >     However, when a correct username/password is submitted but the user 
>does
> > not
> >     possess an adequate role, I see a default "You are not authorized"
> > message.
> >     How can I customize the page that is shown in such circumstances ?
> >
>
>You can use an <error-page> element in your web.xml for the 403 status.

Thank you. I was just checking that I hadn't missed something.
I had expected an equivalent to  <form-error-page> which would allow
one to tailor the authorization-failure to the section of the webapp.


> > 4. Is there a formal method to logging out, rather than calling
> >    invalidate() on the session ?
> >
>
>Not in Servlet 2.3.  Such things are under consideration for 2.4.  For
>now, invalidating the session is the right way to do it (if you're using
>form based login).
>
> > 5. If your webapp's authentication works fine on Tomcat, would it then
> >    work on say BEAWeblogic or IBMWebsphere ?
> >
>
>As long as you are not relying on wierd container-specific behaviors and
>using j_security_check the way it was intended to be used.
>
>Note that the user database itself, and how you set it up, will be
>specific for each app server (i.e. JDBCRealm is Tomcat specific).  But the
>app won't have to change.

Thank you for the clarification, Craig.

Soefara.


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to