Léa,
Life needn't be this difficult. :-) You're reinventing wheels here
instead of understanding how the wheels you already have work. Again,
read the spec. Pretty please. So many questions will be answered.
On Fri, 2011-11-04 at 11:55 -0700, Léa Massiot wrote:
> @Christopher :
> Thank you for your answer.
>
> Christopher wrote:
> >
> > The new session created is completely empty. It has nothing to do with the
> > user going back in the history, etc.
> > No, you are right.
> What I meant is that I was/am managing session expiration inside the Webapp
> (for instance if the user clicks a button which is inside the Webapp and if
> the session has expired, I redirect him to the log in page).
>
> Christopher wrote:
> >
> > I always try to have enough information in the page (form) so that
> > resuming a workflow after a session timeout is a possibility.
> >
> I'm sorry but I do not understand what you are explaining me here...
>
>
> A SOLUTION... I THINK.
> I have found a solution, here it is:
> for all the JSPs which require a user to be identified (*), I add the
> following code:
>
Better solution is to check whether the user principle is set. The spec
will explain this.
> <%
> ASessionAttribute aSessionAttribute = null;
> HttpSession httpSession = null;
>
> httpSession = request.getSession();
> aSessionAttribute = (ASessionAttribute)
> httpSession.getAttribute("aSessionAttribute");
>
> if(aSessionAttribute == null)
> {
> response.sendRedirect("the-log-in-page.jsp");
> }
> %>
>
> Then if a user presses the F5 key and if the session has expired, he is
> properly redirected to the log in page.
>
> Best regards,
> --
> Léa
>
> (*) That is to say, in my example, the "aSessionAttribute" object musn't be
> null.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
