https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
--- Comment #6 from Mark Thomas ---
Slight change of plan.
10.1.x will just fix this (the 10.1.x releases are still milestones).
10.0.x and earlier will fix this but sending the new messages will be
controlled by configuration and disabled
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
--- Comment #5 from Mark Thomas ---
Having started work on this it is more complex that it first appears.
The main reason is needing to make sure a cluster can perform a rolling
upgrade. Getting this to work in a Tribes based cluster requires
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
--- Comment #4 from psakkanan ---
I like making it optional
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
--- Comment #3 from Mark Thomas ---
My current thinking is that make this behaviour optional depending on the
setting of the "persistAuthentication" attribute of the Manager.
If we do this that way, the change to the session serialization
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
--- Comment #2 from psakkanan ---
Please remember that this issue would pop as random login failure ( on
Kubernetes or similar cloud infra) mostly on prod/deployed env.
It took weeks for us to deduce this issue from random login error to
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
--- Comment #1 from Mark Thomas ---
Do we want to support this? It would mean finding a way to serialize:
- the expected session ID (part of the CSRF protection)
- the saved request
This looks to be doable although it would some effort to
https://bz.apache.org/bugzilla/show_bug.cgi?id=66120
psakkanan changed:
What|Removed |Added
Summary|j_security_check returns|j_security_check returns
