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:

    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
this before?
Or can I "remap" the old pagestore to the new session?

Thanks for any input,


Sent from:

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to