-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
None
As described in this forum post and in the following reproducer application when an HttpSesion is created from a secured call without previous provided JSESSIONID, the generated JSESSIONID is not stable and is regenerated by a next secured call.
This behavior causes calls failures if several parallel calls are fired behind the first one.
Why the generated JSESSIONID is not trusted whereas it is issued by a secure call without previous JSESSIONID?
The only workarounds I have found so far are:
- make an unnecessary secured call in order to stabilize the JSESSIONID before the parallel calls are fired
- or deactivate ChangeSessionIdOnLogin feature by the use of an undertow servlet extension (introduction of security issue)
- clones
-
JBEAP-9706 JSESSIONID not trusted by CachedAuthenticatedSessionHandler
- Closed
- incorporates
-
UNDERTOW-1006 JSESSIONID not trusted by CachedAuthenticatedSessionHandler
- Resolved
- is incorporated by
-
JBEAP-8650 (7.0.z) Upgrade undertow from 1.3.27.Final to 1.3.28.Final
- Closed