Steve Kirk
Mon, 23 May 2005 05:39:44 -0700
OK no problem, I'm learning something here too :) I agree, one app cannot access a session created by another app (unless you set singlesignon, which we'll ignore for now).
I am referring just to the single line I quoted earlier, from SRV.7.3 of 2.4
spec. I'm reading that as saying that if app A creates session X for user
U, then the user U then accesses app B, which then includes a servlet from
app A via its RequestDispatcher as you have done in your example, context A
will not have access to the session in the second request, even though it
created it, because it was routed through app B, which is not allowed to
access it.
I might have misinterpreted this, because I have no actual experience of it.
I can see that it might be possible that the session is invisible to B but
not A. If so I'm more than happy to be told I'm wrong by someone who
knows....?
> -----Original Message-----
> From: Akoulov, Alexandre [IT]
> [EMAIL PROTECTED]
> Sent: Monday 23 May 2005 10:46
> To: Tomcat Users List
> Subject: RE: problem: Session invalidation in the servlet
> accessed via foreign context
>
>
> Thanks, Steve, again.
>
> >That's what I'm
> >reading the servlet 2.4 spec as saying, because you can't
> invalidate a
> >session in one context that is not accessible to you in
> another context,
> >irrespective of whether you use getRequestDispatcher to do that.
>
> What section of the spec defines such behaviour? I understand
> that we cannot access a session created by one application
> from another one. However, an application can manage its own
> session(s) and the way the application is accessed (via
> RequestDispatcher or via direct hit) should not affect
> session management at all.
>
> Thanks again, I really appreciate your thoughts on this matter.
>
>
> Kind regards,
>
> Alex.
>
>
> -----Original Message-----
> From: Steve Kirk [EMAIL PROTECTED]
> Sent: Monday, 23 May 2005 6:21 PM
> To: 'Tomcat Users List'
> Subject: RE: problem: Session invalidation in the servlet accessed via
> foreign context
>
>
>
> OK.
>
> So... your conclusion is that you can't do that, right?
> That's what I'm
> reading the servlet 2.4 spec as saying, because you can't invalidate a
> session in one context that is not accessible to you in
> another context,
> irrespective of whether you use getRequestDispatcher to do that.
>
> Or maybe I'm reading it wrong. That's possible as to be
> honest I've never
> tried what you're trying for real, I'm going on what the docs say not
> personal experience.
>
> > -----Original Message-----
> > From: Akoulov, Alexandre [IT]
> > [EMAIL PROTECTED]
> > Sent: Monday 23 May 2005 06:53
> > To: Tomcat Users List
> > Subject: RE: problem: Session invalidation in the servlet
> > accessed via foreign context
> >
> >
> > Thanks again, Steve, for your time.
> >
> > I am not trying to share sessions between different apps. I
> > just want to ensure that when we're programmatically
> > accessing web application in the different context it can do
> > its own session management (ie invalidate / create new ones)
> >
> > -----Original Message-----
> > From: Steve Kirk [EMAIL PROTECTED]
> > Sent: Monday, 23 May 2005 11:52 AM
> > To: 'Tomcat Users List'
> > Subject: RE: problem: Session invalidation in the servlet
> accessed via
> > foreign context
> >
> >
> >
> > I'm not sure why you think there is a problem with
> > invalidation. I'm no
> > expert, but I'm not sure that I would expect the code below
> > to work, because
> > by default, servlets must not share sessions between webapps,
> > and you are
> > asking that a client request to one context is passed to
> > another, and still
> > the session data is available. Withouht single sign-on, I
> would have
> > thought that sessions will not be shared.
> >
> > I've just flipped through the 2.4 servlet spec. Section
> SRV.7.3 says
> > something very specific about your scenario, as follows: "if
> > a servlet uses
> > the RequestDispatcher to call a servlet in another Web
> > application, any
> > sessions created for and visible to the servlet being called must be
> > different from those visible to the calling servlet."
> >
> > I appreciate that you are also saying that v3/v4 behaved
> > differently - but
> > are you sure that the config of those versions was not
> > different, perhaps
> > they were configured to share sessions (single sign-on)? I'm
> > not sure on
> > the detail of earlier versions of the servlet spec, but
> > perhaps session
> > behaviour was defined differently in previous versions. You
> > could find out
> > with a google search, or maybe someone else will answer....
> >
> > > -----Original Message-----
> > > From: Akoulov, Alexandre [IT]
> > > [EMAIL PROTECTED]
> > > Sent: Monday 23 May 2005 01:29
> > > To: Tomcat Users List
> > > Subject: RE: problem: Session invalidation in the servlet
> > > accessed via foreign context
> > >
> > >
> > > Thanks a lot, Steve, for your reply.
> > >
> > > No, I am not using SingleSignOn neither hoping to share the
> > > same session across contexts.
> > >
> > > The only thing I was testing is that I could invalidate and
> > > then create a new session in different scenarios.
> > >
> > > I ran the test with the java debugger and could observe that
> > > when invalidating/creating a session in ForeignContextServlet
> > > it in fact did not create a new session and left us with the
> > > reference to old (ie invalidated) session after line No.3.
> > >
> > > My next step is start looking into the tomcat source code to
> > > try to work out what's happening. Do you think it's best way
> > > to approach this issue?
> > >
> > >
> > > Thanks again,
> > >
> > > Alex.
> > >
> > > -----Original Message-----
> > > From: Steve Kirk [EMAIL PROTECTED]
> > > Sent: Monday, 23 May 2005 10:18 AM
> > > To: 'Tomcat Users List'
> > > Subject: RE: problem: Session invalidation in the servlet
> > accessed via
> > > foreign context
> > >
> > >
> > >
> > > I'm not sure I fully understand this issue, but seeing as
> > > no-one else seems
> > > to have replied yet, maybe a few Qs might help you work
> through it:
> > >
> > > Are you hoping that both contexts will share their sessions?
> > >
> > > Are you using the SingleSignOn feature in server.xml?
> > >
> > > When you say that ForeignContextServlet does not create a
> > new session
> > > object, are you explicitly testing that within
> > > ForeignContextServlet itself,
> > > or from a servlet in another context (e.g.
> > DebuggerServlet)? i.e. is
> > > null==session after step 3?
> > >
> > > You say that the session is invalid/null after line 2, but
> > > have you tested
> > > that it was valid/non-null before line 2?
> > >
> > > > -----Original Message-----
> > > > From: Akoulov, Alexandre [IT]
> > > > [EMAIL PROTECTED]
> > > > Sent: Monday 23 May 2005 00:43
> > > > To: tomcat-user@jakarta.apache.org
> > > > Subject: Re: problem: Session invalidation in the servlet
> > > > accessed via foreign context
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > I'd greatly appreciate if you could shed a ray of light on
> > > > the following problem ( see below)
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Akoulov, Alexandre [IT]
> > > > Sent: Friday, 20 May 2005 11:15 AM
> > > > To: Tomcat Users List
> > > > Subject: problem: Session invalidation in the servlet
> accessed via
> > > > foreign context
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > It seems that there is a problem with session invalidation in
> > > > tomcat5.0. Please refer to the explanation below:
> > > >
> > > >
> > > > 1. HttpSession session = req.getSession(true); // get
> > > > existing user session or create one if does not exist
> > > > 2. session.invalidate(); // invalidate user session
> > >
> > > > 3. session = req.getSession(true); // create a new session (
> > > > ie a valid session)
> > > >
> > > > The above three lines of code are commonly used to invalidate
> > > > the user session and then create a new one. Tomcat implements
> > > > this behaviour by creating a new session object in line No.3.
> > > > However, in tomcat5.0 implementation (5.0.28) when the above
> > > > code is accessed via foreign context it does not create a new
> > > > session object and therefore a session is still invalid after
> > > > lineNo.3 is executed. The following code demonstrates the
> > > > problem:
> > > >
> > > >
> > > > // servlet that runs in the same tomcat instance but in a
> > > > different context to DebuggerServlet's context
> > > > public class ForeignContextServlet extends HttpServlet {
> > > > public void doGet(HttpServletRequest req,
> > > > HttpServletResponse res)
> > > > throws ServletException, IOException {
> > > >
> > > > HttpSession session = req.getSession(true);
> > > >
> > > > session.invalidate();
> > > > session = req.getSession(true); //
> > > > !!!!!!PROBLEM!!!!!!!!!! does NOT create a new session when
> > > > accessed via foreign context's dispatcher
> > > > }
> > > > }
> > > >
> > > >
> > > > // servlet that accesses ForeignContextServlet via foreign
> > > > context's dispatcher
> > > > public class DebuggerServlet extends HttpServlet {
> > > > public void doGet(HttpServletRequest req,
> > > > HttpServletResponse res)
> > > > throws ServletException, IOException {
> > > >
> > > > ServletContext ctx = getServletContext();
> > > >
> > > > // dispatch the request to the servlet in a
> > > different context
> > > > ServletContext foreignContext =
> > > > ctx.getContext("/AccessCommon");
> > > >
> > > > foreignContext.getRequestDispatcher("/foreignContextServlet").
> > > > include(req, res);
> > > > }
> > > > }
> > > >
> > > > Such behaviour is only observed in tomcat 5.0 (have not tried
> > > > on tomcat5.5); tomcat3 and tomcat4 do create new session
> > > > objects in lineNo.3
> > > >
> > > >
> > > > I greatly appreciate your comments on this issue.
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Alex.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]