Dear Chris,

Thank you very much.  I can get the link redirect.  But the tomcat's
container security seems to happen before it.  Here is the stuff in
the web.xml.  When I type
http://localhost:8080/InformProject/pages/login.jsp, it will redirect
to https://localhost:8443/.....  The browser will alert me because it
is self-certified. But when I go other pages, which should bring this
login page up, it just bring up the http plain version and bypass this
redirection.

<web-resource-collection>
 <web-resource-name>login page</web-resource-name>
   <url-pattern>/pages/login.jsp</url-pattern>
 </web-resource-collection>
 <user-data-constraint>
   <transport-guarantee>CONFIDENTIAL</transport-guarantee>
 </user-data-constraint>
</security-constraint>
<login-config>
                <auth-method>FORM</auth-method>
                <form-login-config>
                        <form-login-page>/pages/login.jsp</form-login-page>
                        <form-error-page>/pages/error.jsp</form-error-page>
                </form-login-config>
        </login-config>

Sincerely yours
Zhu, Guojun


On Wed, May 6, 2009 at 8:54 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Guojun,
>
> On 5/6/2009 3:05 PM, Guojun Zhu wrote:
>> We had a small web application on tomcat 5.5.  We use tomcat realm
>> (MD5 digest)  with the form-based login.  I have a few questions on
>> this.
>>
>> 1.  When we use http, does the form-based login page send the username
>> and password plainly or in the digested form?
>
> Your web browser will send the credentials in cleartext. The only
> "digest" being used here is the one used to hash the password before it
> is checked against your database (all on the server side).
>
> If you want the password sent securely, you'll need to either use HTTPS
> or use DIGEST authentication, which uses HTTP Auth instead of forms. I
> prefer HTTPS + form over DIGEST, FWIW.
>
>> 2.  We set up the ssl in 8443 port.  All links in our application are
>> relative link without the specified scheme.   So currently all the
>> links (including login page) go either through normal http or
>> encrypted https.  Is there anyway to limit the ssl only for the login
>> page alone and make sure login page always go through ssl?  Rest pages
>> are really fairly low-risk stuff and we do not worry about the leak on
>> them.
>
> Are you comfortable with the possibility of session hijacking? If so,
> there is a way to do this that I outlined a few weeks ago. Hmm... I
> can't seem to find it in the archives; I'll give you the short-short
> version. Try something like this:
>
> web.xml:
> <form-login-page>/login.jsp</form-login-page>
> ...
> <security-constraint>
>  <web-resource-collection>
>    <url-pattern>/login.jsp</url-pattern>
>  </web-resource-collection>
>  <user-data-constraint>
>    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>  </user-data-constraint>
> <security-constraint>
>
> login.jsp:
> <%
>   Cookie mySessionCookie = ...;
>   if(mySessionCookie.isSecure())
>   {
>      // We don't want a secure session cookie. Kill it,
>      // redirect to non-secure page and bounce back.
>
>      session.invalidate();
>
>      response.sendRedirect(response.encodeRedirectURL(BOUNCE_PAGE));
>   }
> %>
>
> Your bounce page should simply create a session and redirect to
> https://yourhost/login.jsp.
>
> You should probably create a filter that watches every URL except your
> login page and drives everything back to HTTP if it finds HTTPS in use.
>
> This may interfere with the container's ability to store and re-play
> requests for protected resources /after/ a successful login. YMMV. If
> you can't get it working using this suggestion, feel free to hire me to
> do it for you ;)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkoCPzoACgkQ9CaO5/Lv0PAPnwCcC9jIfZ9oc60imAgaw01sfcjJ
> MlEAoIsyPZ9f6dXGo5IInzLXOMxh7vs0
> =9YPw
> -----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

Reply via email to