Thanks for pointing that out. I've tried some other changes, so I'll wait and see how they work out. However, if the problem persists I'll look into the possibility of it being an HTTPS-related issue. That line of reasoning hadn't ever occurred to me.
Dane On Thu, Jun 11, 2009 at 1:09 PM, Igor Vaynberg <[email protected]> wrote: > > good catch Jason. > > We have also ran into this when implementing wicket's @RequireHttps > annotation, there is a javadoc section in HttpsRequestCycleProtocol > that talks about this cookie pain. > > -igor > > On Thu, Jun 11, 2009 at 1:03 PM, Jason Lea<[email protected]> wrote: > > I notice there are some secure requests there (https)... so I will now > > blindly assume you are having the same problem I had in the past... > > > > I had a problem with session ids changing when trying to swtich between > > secure/insecure pages. > > If your first request to a tomcat server is secure, and a session is > > created, tomcat will create a secure session id cookie that will only be > > sent in https requests. If you request a non-secure (http) page request it > > will not send the cookie, and a new insecure session cookie is created. > > > > One way to fix* this is to use a http request filter that checks for new > > session id cookie creation, and writing a new insecure cookie if a secure > > one has been created. Something like this: > > http://forum.springsource.org/archive/index.php/t-65651.html > > > > *when I say fix, I mean make the system less secure :) > > > > Igor Vaynberg wrote: > >> > >> yes, a changing sessionid will cause a page expired error because the > >> client all of a sudden gets a new blank session. > >> > >> changing session ids can be caused by either session expiration or a > >> manual session invalidation - like during a logout procedure. > >> > >> you have to figure out what causes the session to get dumped and a new > >> one to be created in your application/servlet container. > >> > >> -igor > >> > >> On Thu, Jun 11, 2009 at 9:56 AM, Dane Laverty<[email protected]> > >> wrote: > >> > >>> > >>> I'm trying to track down the source of frequent PageExpiredExceptions > >>> that > >>> we're getting on our deployment server. One of the errors occured at > >>> 01:28:06 this morning. In the Apache logs, I discovered that the user's > >>> session ID spontaneously changed at that time, (see the change between > >>> lines > >>> 4 & 5 below, and then again between lines 11 & 12). Is that just a > >>> coincidence, or would a changing session ID cause the > >>> PageExpiredException? > >>> And if so, what causes the session ID to change? (I'm using Wicket 1.3.6. > >>> I > >>> can't replicate the errors in development, which sounds common according > >>> to > >>> the several PageExpiredException threads. I'm not seeing any sort of > >>> serialization errors either.) Thanks for your help! > >>> > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:03 -0700] "GET > >>> /resources/comp.Comp/Oregon2.jpg HTTP/1.1" 200 22145 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:03 -0700] "GET > >>> /resources/comp.Comp/newVGrad.png HTTP/1.1" 200 48736 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:03 -0700] "GET > >>> /resources/comp.Comp/navBoxBottom.jpg HTTP/1.1" 200 14140 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:05 -0700] "GET > >>> /pay%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3 HTTP/1.1" 302 - "-"... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:05 -0700] "GET > >>> /foodhandler/login;jsessionid=271042707F280E26F7A08E6FFF108C22 HTTP/1.1" > >>> 302 > >>> 263 "-"... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:05 -0700] "GET > >>> /login%3bjsessionid=271042707F280E26F7A08E6FFF108C22 HTTP/1.1" 200 8056 > >>> "-"... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:06 -0700] "GET > >>> /resources/comp.Comp/main.css HTTP/1.1" 200 9904 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=271042707F280E26F7A08E6FFF108C22 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:06 -0700] "GET > >>> /resources/comp.Comp/print.css HTTP/1.1" 200 459 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=271042707F280E26F7A08E6FFF108C22 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:06 -0700] "GET > >>> > >>> /resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js;jsessionid=271042707F280E26F7A08E6FFF108C22 > >>> HTTP/1.1" 200 8939 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=271042707F280E26F7A08E6FFF108C22 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:06 -0700] "GET > >>> > >>> /resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js;jsessionid=271042707F280E26F7A08E6FFF108C22 > >>> HTTP/1.1" 200 1184 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=271042707F280E26F7A08E6FFF108C22 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:06 -0700] "GET > >>> /resources/comp.Comp/prototype.js HTTP/1.1" 200 47603 " > >>> > >>> https://www.foodhandler.org/login%3bjsessionid=271042707F280E26F7A08E6FFF108C22 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:06 -0700] "GET > >>> /%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3?wicket:interface=:12:::: > >>> HTTP/1.1" 200 4623 " > >>> > >>> https://www.foodhandler.org/take-the-test%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3 > >>> "... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:07 -0700] "GET > >>> /resources/comp.Comp/main.css HTTP/1.1" 200 9904 " > >>> > >>> https://www.foodhandler.org/%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3?wicket:interface=:12: :: > >>> :"... > >>> XXX.XXX.29.22 - - [11/Jun/2009:01:28:07 -0700] "GET > >>> /resources/comp.Comp/print.css HTTP/1.1" 200 459 " > >>> > >>> https://www.foodhandler.org/%3bjsessionid=E0381EA98B6C107CD1D4DF8FDE5D88C3?wicket:interface=:12: :: > >>> :"... > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> > > > > -- > > Jason Lea > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
