Hi Ravi!
We fixed this in all of our apps with a custom servlet response wrapper
(our NonEncodingHttpServletResponse), which prevents the application from
ever putting a session id into the url.
It’s a simple extension of HttpServletResponseWrapper which simply returns
the provided url in all four encode* methods.
We install it by overriding newWebResponse in our wicket application:
@Override
protected WebResponse newWebResponse( final WebRequest webRequest,
HttpServletResponse servletResponse )
{
// Make sure we never get JSESSIONID in the url
return super.newWebResponse( webRequest, new
NonEncodingHttpServletResponse( servletResponse ) );
}
Please note that this means clients which don’t accept cookies will not be
able to work with a session, but that has never been an issue for us. In
our case we never want a session id in urls, as our app has a lot of pages
indexed by google.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 18 mei 2018 bij 12:21:24, Ravi (ravi.k...@intellinet.de) schreef:
Hi all,
we have a single page application (SPA). On the first entree we of course
get a Session url that will never disappear due to the nature of an SPA.
So what we do is a session replacement on the first button click to battle
Session Hijacking when posting the link in some forum.
For a single tab that works just fine.
If you have two tabs open and tab A fires a sessionreplacement, it clears
the pagestore, causing to loose the page that is displayed on tag B.
Interacxtion with tab B then leads to a session expired page.
Is there any best practice or has someone of you guys tackled something
like
this before?
Or can I "remap" the old pagestore to the new session?
Thanks for any input,
Ravi
--
Sent from:
http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
