I too would like to know the Wicket answer. The problem is that
JSESSIONID is how the Servlet container differentiates the session with
the user. It's part of the spec since the beginning. Because it is
well known and certain browsers (Firefox, representing over a third of
browser clients) make
Cant you use
http://www.mkyong.com/wicket/how-do-encrypt-encode-url-in-wicket/
But I guess it might still get the session id appended..?
2009/12/2 Loritsch, Berin C. berin.lorit...@gd-ais.com
I too would like to know the Wicket answer. The problem is that
JSESSIONID is how the Servlet
This is not a Wicket issue. However, there is a good discussion on
the topic here:
http://old.nabble.com/JSESSIONID-hijacking-td22492701.html
What application server are you using?
On Wed, Dec 2, 2009 at 4:24 AM, Andrew Turner grim_toas...@hotmail.com wrote:
Good morning all,
I'm hoping
The Seam folks have a fix for removing JSESSIONID from the URLs, too:
http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache
On Wed, Dec 2, 2009 at 9:31 AM, James Carman
jcar...@carmanconsulting.com wrote:
This is not a Wicket issue. However, there is a good
Thats basically the same code as on
http://randomcoder.com/articles/jsessionid-considered-harmful.
OWASP also has a good deal to say about sessions:
http://www.owasp.org/index.php/Session_Management
Regards,
Erik.
James Carman wrote:
The Seam folks have a fix for removing JSESSIONID
2009/12/2 Andrew Turner grim_toas...@hotmail.com:
Good morning all,
I'm hoping I've misconfigured something in my application, but we seem to be
prone to session stealing in our wicket application. We're using
wicket-auth-roles to provide the security, and if you are able to access the
Marvellous, thanks for the input folks. So, in a nutshell, what we're
basically saying is that when using Wicket we recommend HTTPS and disabling URL
rewrite (we are using weblogic and I presumed one of the other settings should
have disabled URL rewrite, the fool I am, cookie-secure seemed
