[
https://issues.apache.org/jira/browse/WICKET-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545831#comment-13545831
]
Dominik Drzewiecki edited comment on WICKET-4952 at 1/7/13 12:38 PM:
---------------------------------------------------------------------
Consider an application where you build up your session data and at some point
you decide to log in. A simple shopping application with a shopping cart comes
to my mind. The cart is intentionally *not* made persistent but rather exists
within the scope of a session as there is yet no user id this persistent cart
been be bound to.
I disagree that upon login the session state should mandatorily be flushed. The
whole point with #replaceSession() is to keep the session contents and replace
the id only thus prevent session fixation attack. Please consider that at the
same time wicket session object remains intact and is rebound to the new http
session.
Please observe, that some containers (Tomcat and its authenticator valves)
start to implement session id regeneration after successful authentication
against configured realm
(http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Basic_Authenticator_Valve
, changeSessionIdOnAuthentication that defaults to true). I doubt that the
whole session gets flushed then, I expect only a brand new session id to be
returned. This feature's emergence leads me to the conclusion that
#replaceSession() should belong to Servlet API.
was (Author: drzewo):
Consider an application where you build up your session data and at some
point you decide to log in. A simple shopping application with a shopping cart
comes to my mind. The cart is intentionally *not* made persistent but rather
exists within the scope of a session as there is yet no user id this persistent
cart been be bound to.
I disagree that upon login the session state should mandatorily be flushed. The
whole point with #replaceSession() is to keep the session contents and replace
the id only thus prevent session fixation attack. Please consider that at the
same time wicket session object remains intact and is rebound the the new http
session.
Please observe, that some containers (Tomcat and its authenticator valves)
start to implement session id regeneration after successful authentication
against configured realm
(http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Basic_Authenticator_Valve
, changeSessionIdOnAuthentication that defaults to true). I doubt that the
sole session gets flushed then, I expect only a brand new session id to be
returned. This feature emergence leads me to the conclusion that
#replaceSession() should belong to Servlet API.
> Wicket-CDI and o.a.w.Session.replaceSession() do not play nice.
> ---------------------------------------------------------------
>
> Key: WICKET-4952
> URL: https://issues.apache.org/jira/browse/WICKET-4952
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-cdi
> Affects Versions: 6.3.0, 6.4.0
> Reporter: Dominik Drzewiecki
>
> As CDI session-scoped beans are bound to the session, invoking
> o.a.w.Session.replaceSession() results in destoroying HttpSession and all
> bound beans. Maybe we could provide some hack to workaround this so that the
> beans wo't get flushed and be rebound to the newly created HttPSession?
> It is an evident servlet APIs shortcoming; it definitely lacks some more
> standard replaceSession() in its API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
