You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by as...@huji.013.net.il on 2004/07/05 09:50:46 UTC
session invalidation
hello,
1. a webapp has a filter, which filters all of the requests to application's servlets.
2. the filter makes a simple check:
if (session == null || session.getAttribute("abc") == null)
//redirect the request to the login page;
else
//continue with it as it is
3. if i invalidate the session, and then try to use back button of the browser the filter kicks me to the login page.
on tomcat4 this works fine. at least i didn't see any problem ever.
4. on tomcat 5 this logic works fine only with browser whith enabled cookies. using the session tracking with url rewriting doesn't work.works the debugging shows that the flow runs into the code block that must invalidate the session, but it's not invalidated. i still can get back,see the pages and use the data stored in session!:(
did u have any expirience with this stuff?
thanks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session invalidation
Posted by Asher Tarnopolski <as...@huji.013.net.il>.
hey jake and others, thanks for help.
i tried the same code on tc5.0.25 and it has the same
problem as tv 5.0.16.
the debugging showed that when i enter a site after
the session should be already invalidated,
the request passes the filter including the code block
that checks if session is valid.
from there it ccontinues as if the session would be
still alive and kicking. actually, it's still
alive . the session bound attributes are still
available and the redirections are made with the same
jsessionid in the rewrited url as earlier.
as i wrote, with cookies based session tracking (no
url rewriting) everything works fine.
the filter in my code only checks if the session is
valid, the invalidation is made in a regular
servlet, which makes me think that this is not related
to some filters-specific bug.
may be i'll post this to bugzilla later...
asher
----- Original Message -----
From: "Jacob Kjome" <ho...@visi.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Monday, July 05, 2004 8:53 PM
Subject: Re: session invalidation
> At 10:15 AM 7/5/2004 +0200, you wrote:
> >Hello Ashert,
> >
> >may be you ran into the same prob as me....
> >
> >i also had the problem, that URL-rewriting under Tomcat 5 did not work
> >although i explicitly used it. I found out, that URL-rewriting does only
> >work, if your application runs in the root context, looking like that in
> >server.xml:
> >
> ><Context path="" docBase="myWebapp" cookies="false" />
> >
> >I was running my app under a named context:
> >
> ><Context path="myWebapp" docBase="myWebapp" cookies="false" />
> >
> >After changing the context definition to the first sample, URL-rewriting
> >worked fine....
> >
> >hope this helps & best regards,
>
> Well, this helps very little. If you want to help, then provide the
> version of Tomcat5 you are working with. For all we know it is an old
> version with a quirky bug that has already been fixed in more recent
> versions. And if that is true, you are just adding to the confusion
saying
> it is broken when it isn't anymore. If it is still broken, however, it is
> your duty to report the bug so it can be fixed. Have you done that or
even
> checked if someone else reported it? The Tomcat developers are pretty
> responsive to fixing bugs. If you have the ability to describe and
> reproduce this bug and you neglect to do so, then you are doing a
> disservice to the Tomcat community. Some might disagree with the whole
"it
> is your duty" part. It is an unwritten rule that, if followed, will
> provide benefit to yourself and everyone else.
>
> Jake
>
>
> >Thilo
> >
> >>hello,
> >>
> >>1. a webapp has a filter, which filters all of the requests to
> >>application's servlets.
> >>2. the filter makes a simple check:
> >>if (session == null || session.getAttribute("abc") == null)
> >>//redirect the request to the login page;
> >>else
> >>//continue with it as it is
> >>3. if i invalidate the session, and then try to use back button of the
> >>browser the filter kicks me to the login page.
> >>on tomcat4 this works fine. at least i didn't see any problem ever.
> >>4. on tomcat 5 this logic works fine only with browser whith enabled
> >>cookies. using the session tracking with url rewriting doesn't
work.works
> >>the debugging shows that the flow runs into the code block that must
> >>invalidate the session, but it's not invalidated. i still can get
> >>back,see the pages and use the data stored in session!:(
> >>did u have any expirience with this stuff?
> >>thanks in advance.
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session invalidation
Posted by Jacob Kjome <ho...@visi.com>.
At 10:05 PM 7/5/2004 +0200, you wrote:
>hey jacob,
>
>i tried it on 5.0.16.
That's better, now we know that we're dealing with an old release.
>there is always a chance this was fixed since that version.
>i didn't find anything about it in the bugzilla. that's why i posted
>just to ask if someone already met this problem .
You had a valid post asking a question (although neglected to mention the
version, but that's less important in the context of your question). Note
that my response was to Thilo, not to you, because he claimed there existed
a bug, but didn't mention any bug report he had made, nor the version with
which he was seeing the bug occur. He did more harm than good by posting.
>i posted another bug earlier (see my utf-8 problem posts) and got an
>answer that this is not a bug, but the attached solution didn't solve my
>problem.
I'm glad to see you are active in not only helping yourself, but the
project as a whole by taking the initiative to post a bug when you
encounter it. Sorry you haven't found a solution yet!
>when i reposted, the answer was that i should write to this board.
Yep, sounds like a good idea to me.
>and please, leave the DUTIES stuff for other discussions.
Being that my response was in no way directed at your post, I fail to see
how this is relevant to a discussion between the two of us.
Jake
>asher.
>
>----- Original Message -----
>From: "Jacob Kjome" <ho...@visi.com>
>To: "Tomcat Users List" <to...@jakarta.apache.org>
>Sent: Monday, July 05, 2004 8:53 PM
>Subject: Re: session invalidation
>
>
> > At 10:15 AM 7/5/2004 +0200, you wrote:
> > >Hello Ashert,
> > >
> > >may be you ran into the same prob as me....
> > >
> > >i also had the problem, that URL-rewriting under Tomcat 5 did not work
> > >although i explicitly used it. I found out, that URL-rewriting does only
> > >work, if your application runs in the root context, looking like that in
> > >server.xml:
> > >
> > ><Context path="" docBase="myWebapp" cookies="false" />
> > >
> > >I was running my app under a named context:
> > >
> > ><Context path="myWebapp" docBase="myWebapp" cookies="false" />
> > >
> > >After changing the context definition to the first sample, URL-rewriting
> > >worked fine....
> > >
> > >hope this helps & best regards,
> >
> > Well, this helps very little. If you want to help, then provide the
> > version of Tomcat5 you are working with. For all we know it is an old
> > version with a quirky bug that has already been fixed in more recent
> > versions. And if that is true, you are just adding to the confusion
>saying
> > it is broken when it isn't anymore. If it is still broken, however, it is
> > your duty to report the bug so it can be fixed. Have you done that or
>even
> > checked if someone else reported it? The Tomcat developers are pretty
> > responsive to fixing bugs. If you have the ability to describe and
> > reproduce this bug and you neglect to do so, then you are doing a
> > disservice to the Tomcat community. Some might disagree with the whole
>"it
> > is your duty" part. It is an unwritten rule that, if followed, will
> > provide benefit to yourself and everyone else.
> >
> > Jake
> >
> >
> > >Thilo
> > >
> > >>hello,
> > >>
> > >>1. a webapp has a filter, which filters all of the requests to
> > >>application's servlets.
> > >>2. the filter makes a simple check:
> > >>if (session == null || session.getAttribute("abc") == null)
> > >>//redirect the request to the login page;
> > >>else
> > >>//continue with it as it is
> > >>3. if i invalidate the session, and then try to use back button of the
> > >>browser the filter kicks me to the login page.
> > >>on tomcat4 this works fine. at least i didn't see any problem ever.
> > >>4. on tomcat 5 this logic works fine only with browser whith enabled
> > >>cookies. using the session tracking with url rewriting doesn't
>work.works
> > >>the debugging shows that the flow runs into the code block that must
> > >>invalidate the session, but it's not invalidated. i still can get
> > >>back,see the pages and use the data stored in session!:(
> > >>did u have any expirience with this stuff?
> > >>thanks in advance.
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session invalidation
Posted by Asher Tarnopolski <as...@huji.013.net.il>.
hey jacob,
i tried it on 5.0.16.
there is always a chance this was fixed since that version.
i didn't find anything about it in the bugzilla. that's why i posted
just to ask if someone already met this problem .
i posted another bug earlier (see my utf-8 problem posts) and got an
answer that this is not a bug, but the attached solution didn't solve my
problem.
when i reposted, the answer was that i should write to this board.
and please, leave the DUTIES stuff for other discussions.
asher.
----- Original Message -----
From: "Jacob Kjome" <ho...@visi.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Monday, July 05, 2004 8:53 PM
Subject: Re: session invalidation
> At 10:15 AM 7/5/2004 +0200, you wrote:
> >Hello Ashert,
> >
> >may be you ran into the same prob as me....
> >
> >i also had the problem, that URL-rewriting under Tomcat 5 did not work
> >although i explicitly used it. I found out, that URL-rewriting does only
> >work, if your application runs in the root context, looking like that in
> >server.xml:
> >
> ><Context path="" docBase="myWebapp" cookies="false" />
> >
> >I was running my app under a named context:
> >
> ><Context path="myWebapp" docBase="myWebapp" cookies="false" />
> >
> >After changing the context definition to the first sample, URL-rewriting
> >worked fine....
> >
> >hope this helps & best regards,
>
> Well, this helps very little. If you want to help, then provide the
> version of Tomcat5 you are working with. For all we know it is an old
> version with a quirky bug that has already been fixed in more recent
> versions. And if that is true, you are just adding to the confusion
saying
> it is broken when it isn't anymore. If it is still broken, however, it is
> your duty to report the bug so it can be fixed. Have you done that or
even
> checked if someone else reported it? The Tomcat developers are pretty
> responsive to fixing bugs. If you have the ability to describe and
> reproduce this bug and you neglect to do so, then you are doing a
> disservice to the Tomcat community. Some might disagree with the whole
"it
> is your duty" part. It is an unwritten rule that, if followed, will
> provide benefit to yourself and everyone else.
>
> Jake
>
>
> >Thilo
> >
> >>hello,
> >>
> >>1. a webapp has a filter, which filters all of the requests to
> >>application's servlets.
> >>2. the filter makes a simple check:
> >>if (session == null || session.getAttribute("abc") == null)
> >>//redirect the request to the login page;
> >>else
> >>//continue with it as it is
> >>3. if i invalidate the session, and then try to use back button of the
> >>browser the filter kicks me to the login page.
> >>on tomcat4 this works fine. at least i didn't see any problem ever.
> >>4. on tomcat 5 this logic works fine only with browser whith enabled
> >>cookies. using the session tracking with url rewriting doesn't
work.works
> >>the debugging shows that the flow runs into the code block that must
> >>invalidate the session, but it's not invalidated. i still can get
> >>back,see the pages and use the data stored in session!:(
> >>did u have any expirience with this stuff?
> >>thanks in advance.
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session invalidation
Posted by Jacob Kjome <ho...@visi.com>.
At 10:15 AM 7/5/2004 +0200, you wrote:
>Hello Ashert,
>
>may be you ran into the same prob as me....
>
>i also had the problem, that URL-rewriting under Tomcat 5 did not work
>although i explicitly used it. I found out, that URL-rewriting does only
>work, if your application runs in the root context, looking like that in
>server.xml:
>
><Context path="" docBase="myWebapp" cookies="false" />
>
>I was running my app under a named context:
>
><Context path="myWebapp" docBase="myWebapp" cookies="false" />
>
>After changing the context definition to the first sample, URL-rewriting
>worked fine....
>
>hope this helps & best regards,
Well, this helps very little. If you want to help, then provide the
version of Tomcat5 you are working with. For all we know it is an old
version with a quirky bug that has already been fixed in more recent
versions. And if that is true, you are just adding to the confusion saying
it is broken when it isn't anymore. If it is still broken, however, it is
your duty to report the bug so it can be fixed. Have you done that or even
checked if someone else reported it? The Tomcat developers are pretty
responsive to fixing bugs. If you have the ability to describe and
reproduce this bug and you neglect to do so, then you are doing a
disservice to the Tomcat community. Some might disagree with the whole "it
is your duty" part. It is an unwritten rule that, if followed, will
provide benefit to yourself and everyone else.
Jake
>Thilo
>
>>hello,
>>
>>1. a webapp has a filter, which filters all of the requests to
>>application's servlets.
>>2. the filter makes a simple check:
>>if (session == null || session.getAttribute("abc") == null)
>>//redirect the request to the login page;
>>else
>>//continue with it as it is
>>3. if i invalidate the session, and then try to use back button of the
>>browser the filter kicks me to the login page.
>>on tomcat4 this works fine. at least i didn't see any problem ever.
>>4. on tomcat 5 this logic works fine only with browser whith enabled
>>cookies. using the session tracking with url rewriting doesn't work.works
>>the debugging shows that the flow runs into the code block that must
>>invalidate the session, but it's not invalidated. i still can get
>>back,see the pages and use the data stored in session!:(
>>did u have any expirience with this stuff?
>>thanks in advance.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: session invalidation
Posted by Thilo Krawietz <th...@hrs.de>.
Hello Ashert,
may be you ran into the same prob as me....
i also had the problem, that URL-rewriting under Tomcat 5 did not work
although i explicitly used it. I found out, that URL-rewriting does only
work, if your application runs in the root context, looking like that in
server.xml:
<Context path="" docBase="myWebapp" cookies="false" />
I was running my app under a named context:
<Context path="myWebapp" docBase="myWebapp" cookies="false" />
After changing the context definition to the first sample, URL-rewriting
worked fine....
hope this helps & best regards,
Thilo
>hello,
>
>1. a webapp has a filter, which filters all of the requests to application's servlets.
>2. the filter makes a simple check:
>if (session == null || session.getAttribute("abc") == null)
>//redirect the request to the login page;
>else
>//continue with it as it is
>3. if i invalidate the session, and then try to use back button of the browser the filter kicks me to the login page.
>on tomcat4 this works fine. at least i didn't see any problem ever.
>4. on tomcat 5 this logic works fine only with browser whith enabled cookies. using the session tracking with url rewriting doesn't work.works the debugging shows that the flow runs into the code block that must invalidate the session, but it's not invalidated. i still can get back,see the pages and use the data stored in session!:(
>did u have any expirience with this stuff?
>thanks in advance.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org