tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Valves, requests and getting the session
Date Mon, 01 Jul 2002 17:49:30 GMT


On Mon, 1 Jul 2002, John Baker wrote:

> Date: Mon, 1 Jul 2002 09:20:44 +0100
> From: John Baker <jbaker@teamenergy.com>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> Subject: Re: Valves, requests and getting the session
>
> Mmm.
>
> It would appear I can only get the session if the value is defined in the
> Context in server.xml. Ie I cannot define it in the default location in
> server.xml (where the catalina SingleSIgnOn is commented) and expect it to
> work.
>

Ack, you're right ... placement is important, and I missed that subtlety
in your original problem description.

The SingleSignOn valve is embedded in the <Host> element, so that it sees
all the requests for all the webapps installed on that host.  As a
consequence of this, the valve is invoked before the appropriate Context
has been selected (which is done by StandardHostValve, which is always
last on the valves used by the Host).  Therefore, you won't be able to
directly access the session for this request yet, because we don't yet
know which webapp will process the request (and therefore what set of
sessions are relevant).

One workaround is to put your valve inside each <Context> element (either
directly or -- I think this works, but have never tried it -- by embedding
them in a <DefaultContext> that sets the properties for all contexts in
that host.

> Is this correct? And if so, can I achieve what I want to, ie a valve for all
> contexts?
>

You can see how SingleSignOn had to deal with this to identify the
relevant sessions (register itself as a session event listener).  I don't
know how applicable this is to your specific requirements -- but placement
of the SingleSignOn valve under the host is one of the considerations that
led me to the use of a second cookie to carry the user identity across the
webapps that it applies to.

>
> John
>

Craig


> On Sunday 30 June 2002 21:38, John Baker wrote:
> > On Sunday 30 June 2002 9:35 pm, Craig R. McClanahan wrote:
> > > Hmm ... this is baslically how the standard form-based login
> > > implementation creates a session, except that it goes on and gets the
> > > internal Session object ...
> >
> > That's what I thought.
> >
> > > I presume you're trying to create the session *before* calling
> > > context.invokeNext(), right?  If you don't the response will have already
> > > been committed so creating a new session would be ineffective.
> >
> > Yes, I am. I need to check to see if certain objects are in the session and
> > if not, see if they are in another session that is pointed to by the Cookie
> > id. It's like SingleSignOn, but slightly different. However I'm a bit
> > confused to why I can't get a session, even when the rest of the app (the
> > jsp pages etc) are making good use of it.,
> >
> > The headers also show the session id, but oddly enough calling
> > HttpServletRequest.SessionIdFromCookie() returns true, but
> > HttpServletRequest.isRequestSessionIdvalid() returns false!
> >
> >
> > John
>
> --
> John Baker, BSc CS.
> Java Developer, TEAM/Slb. http://www.teamenergy.com
> Views expressed in this mail are my own.
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message