Craig,
Thanks for your comments.
"Craig R. McClanahan" wrote:
>
> On Fri, 4 May 2001, Antony Bowesman wrote:
>
> > Hi,
> >
> > In TC 3.x authenticate() method of a realm is called for every request.
> > (I gather this is changed in 4.x).
> >
>
> You are correct. Tomcat 4 caches the user Principal object returned
> by the authenticate() method in the user's session. If the
> application calls request.isUserInRole() -- or the container is
> enforcing security constraints -- you may or may not have to go
> back to the underlying security realm to look up the role
> information, depending on how you've implemented things. All
> the current Realm implementations cache the assigned roles along
> with the user Principal as well.
Will you be adding a cachable JAAS Subject or LoginContext into TC4 at
any stage, this would move it a little closer to JAAS?
> > I am assuming the RequestImpl is a per HTTP session object. Is
> > this correct? So, each different HTTP session will get a
> > different RequestImpl?
> >
>
> Actually, RequestImpl is per *request*, not per *session*. In
> Tomcat 4, the caching actually happens in the session implementation
> object (it's in the internal Tomcat part of the API).
>
> > If so, when HTTP session times out the authentication for that
> > user is lost. Is it possible to keep the HTTP session alive
> > beyond the configured timeout through some keep alive mechanism?
> > I have a logical session that is container independent and there
> > may have been activity on that session that is not related to
> > the HTTP session and so I want to prevent Tomcat from losing the
> > authenticated context.
> >
>
> Keeping the session alive (beyond the normal timeout mechanism)
> would require tweaking the way that Tomcat does session expiration.
>
> If you want to keep something alive beyond the lifetime of a
> session, it sounds like you might need to store the actual objects
> elsewhere (perhaps in a collection stored as a session context
> attribute), and maintain references to them as session attributes.
> You could use HttpSessionBindingListener events to know when session
> references to the underlying "EJB session" objects are added or
> subtracted. This would also let you share an EJB session across
> multiple HTTP sessions, if that was appropriate for your
> requirements.
Actually, our session is an 'overlying' session. It is not specific to
any container and is available in ORB, EJB, WEB or standalone Java app
so I guess we will set session timeout to -1 and allow our session to
invalidate the HttpSession when it times out.
Rgds
Antony
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
