https://bz.apache.org/bugzilla/show_bug.cgi?id=68742
Bug ID: 68742
Summary: SingleSignOn session invalidation logic fallacy
results in 408 request timed out.
Product: Tomcat 9
Version: 9.0.x
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: messe...@gmail.com
Target Milestone: -----
I'm going to describe the bug as I understand it happens:
Tomcat runs 3 applications, all of which require a session and are unified in a
SSO session.
Define 3 apps:
API - the api
ROOT - creates a session and just redirects to the front
FRONT - handles the frontend
1. User logs in and receives all of the session cookies including the SSO
cookie.
2. User doesn't use the app for a while and the SSO cookie expires, which
redirects to the login page.
3. ONLY the SSO session is invalidated in the client-side and that is the only
session that gets deleted for the client.
4. When accessing the login page, the user accesses the API and the FRONT apps
which results in them getting a new session for those. User doesn't access the
ROOT app and doesn't get a new session for that app (still has the old session)
5. User tries to login and gets a 408 request timed out because he is trying to
login with j_security_check using an already invalidated ROOT session.
I can't think of a single reason, that when the SSO session is invalidated, why
not invalidate all of the session which make up that SSO session (in the client
side).
Why let the client side keep the session cookies for the other sessions when
the SSO one is invalidated.
I do understand that the user just needs to send a request to any of the apps
to receive a new session and I resolved this by just adding a fetch() call to
that app. But I still can't think of a reason that tomcat doesn't tell the
browser to invalidate all of the sessions which corelate to that SSO session.
Would love some clarification and a possible fix?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
