tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rossen Raykov <>
Subject Re: j_security_check requires session
Date Fri, 26 Sep 2008 18:10:59 GMT
... or simply switch to BASIC auth-method.


----- Original Message -----
From: "Christopher Schultz" <>
To: "Tomcat Users List" <>
Sent: Thursday, September 25, 2008 6:42:40 PM GMT -05:00 US/Canada Eastern
Subject: Re: j_security_check requires session

Hash: SHA1

Paul, wrote:
> It seems that tomcat expects that I already have a session established
> before posting the username and password.  If I don't already have a
> JSESSIONID cookie, j_security_check returns a 408.

This behavior adheres to the Servlet Specification. See section 12.5.3.
There is no provision for "drive-by" logins.

> Unfortunately, I
> have another application attempting to talk to this one that requires
> that the first thing it does is post credentials to the
> j_security_check, so I have no mechanism of hitting another page first
> to establish a session.

This is non-portable (as you have seen from moving between servlet
containers). I think you have a couple of options:

1. Change your remote client to first request the desired secure
   resource from the server, then submit the credentials with a second
   request (and you'll be sent to the originally-requested resource,
   as per the spec)

2. Switch to using securityfilter (which allows drive-bys, and which
   Mark already plugged)

3. Remove the security constraint from your target service and implement
   an alternate authentication and authorization strategy (such as
   checking the credentials yourself in the service) manually

> This mechanism worked fine with BEA Weblogic, but it seems that tomcat's
> handling of j_security_check is different.  Does anyone know of any
> options to modify the behavior of j_security_check so that it would just
> do the authentication and establish the session in one shot at the time
> of the POST request?

There are no spec-compliant options. BEA's behavior is an extension to
the servlet specification so whatever you do will be container-specific,
unless you go outside the container-managed security provider (say, by
using something like securityfilter).

- -chris

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message