The sessionid appears in the url when the application is requested for a
first time.
In this case the request doesn't bring JSESSIONID cookie and the server
doesn't know whether cookies are supported/enabled in the browser so it
uses both url rewriting and cookie in the response. When the second request
is comes the server sees the cookie and there is no need to write the
sessionid in the url anymore.
Remove the cookie locally and you will see it in the url.

You can add a session listener to see why the sessions are invalidated. See
Put a breakpoint or dump the stacktrace in onDestroyed.

On Thu, Nov 7, 2013 at 5:06 PM, Marieke Vandamme <marieke.vanda...@tvh.be>wrote:

> Dear wicket users,
> We have an ecommerce platform based on wicket. Since our latest release
> (with wicket 6.8.0) multiple users complain that their session expires too
> early.
> We did not set the timeout in our web.xml or something, so it's handled by
> jetty, and the default of 30 minutes is set there.
> The users we could ask, are using google chrome as browser. One time we
> could see this problem, the jsessionid was present in the url when going to
> the login page.
> Myself I never have this problem, and the jsessionid is never present in my
> url. The user needs to turn on cookies, because this is something that we
> test on the login page, and otherwise no login is possible.
> Has it something to do with the jsessionid? Has anyone else had this
> problem? I know it's hard, because I can not simulate or attach quickstart
> or something.
> Any help is appreciated. Thanks in advance. Kind Regards, Marieke Vandamme
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Session-expires-almost-immediate-after-login-tp4662205.html
> Sent from the Users forum mailing list archive at Nabble.com.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to