-
Bug
-
Resolution: Done
-
Major
-
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
-
UNDERTOW-1006 JSESSIONID not trusted by CachedAuthenticatedSessionHandler
- Resolved
- is cloned by
-
JBEAP-9707 (7.0.x) UNDERTOW-1006 - JSESSIONID not trusted by CachedAuthenticatedSessionHandler
- Closed