+1 I also agree with Sven. I also think that we can improve the current
code by simply using Servlet 3.1, which is the version Wicket 8 is based
on. According to JavaDoc and commit logs Session#replaceSession was
introduced to provide protection against Session Fixation. However
Servlet 3.1 introduced a more efficient way to protect against this
attack with HttpServletRequest#changeSessionId, so we might introduce a
corresponding method in Session class and suggest to use it against
session fixation. More in details it would an abstract method
implemented in WebSession class.
WDYT?
more details about servlet 3.1 here:
https://blogs.oracle.com/arungupta/whats-new-in-servlet-31-java-ee-7-moving-forward
On 02/11/18 08:04, Maxim Solodovnik wrote:
+1
destroy should destroy everything
On Fri, 2 Nov 2018 at 00:37, Sven Meier <[email protected]> wrote:
Hi Andrea,
IMHO destroy() should stay as it is, i.e. "destroy everything".
But replaceSession() shouldn't call it, following its JavaDoc "Replaces
the underlying (Web)Session" it should only invalidate the sessionStore.
WDYT?
Sven
Am 01.11.18 um 17:30 schrieb Andrea Del Bene:
Hi,
about WICKET-6602*, can we keep session metadata on Session#destroy()?
Do you see any problem with it?
Andrea.
* https://issues.apache.org/jira/projects/WICKET/issues/WICKET-6602
