Red Hat Bugzilla – Bug 536032
session oddities when the same user is logged in from multiple machines
Last modified: 2013-09-02 03:24:02 EDT
randomly, one machine will be logged out while the others keep going, and the machine that gets logged out seems to rotate. this might have something to do with the internal session token that the service layer uses, which is supposed to be 1-to-1 with the http session. however, if it's 1-to-1 with the subject entity, then it's easy to see why rotating logouts like this would manifest themselves.
The underlying cause of RHQ-528 is the same thing like here.
Subject has a sessionId. This gets set up upon login() and invalidated on logout().
The call to the business layer will be validated by the RequiredPermissionInterceptor in places where we pass in the Subject as first parameter to a business operation. This one checks if the sessionId of the subject is the same as the current one (iirc) and throws errors when this is not the case - like after the user has logged in a second time.
work around for now is to only have a user login once at a time. will push to 2.0 for further consideration.
from lukas - he did some research and here's what he found:
At heart of the issue we're experiencing is, I believe,
the ...enterprise.server.auth.SessionManager class that implements custom
session management for RHQ.
The main question is: why do we need it? What is the distinction between RHQ
session and an http session? Is it to support WSes and remote EJB calls?
Are there any other problems with the concurrent logins apart from the
apparent "user1 logging out logs out user2 as well" scenario?
The offending method that causes our problems is
SessionManager.getSessionIdFromUsername(String). This method is unfortunately
called from a number of places (excluding tests):
-- boolean isLoggedIn(String username)
this method is never called in app logic - only in tests.
This is remote EJB + web method. The implementation could be changed
to use a new SessionManager's method that would loop over the existing
sessions. What is the usage of this method anyway?
-- Subject login(String username, String password)
in here we actually assign an existing session id to the newly logged
in user if a session for that username already exists. This is
a remote EJB and web method. This method's contract is stating that
the user is associated with an existing session if such session exists
for given username. This is in contrast with the requirement for
allowing multiple logins under the same user name. Why do we need this
We return the Subject instance with the session id initialized so the
remote endpoints know their session ids. Why do we then need the
login method to support the "reattaching" behaviour?
login of the newly registered user
logs in the user
-- loginUnauthenticated(String username, boolean reattach)
if reattach==true and a user already exists - the newly logged in user
shares a session with the previously logged in user.
This is only a EJB local method.
This is problematic method, because it only requires a username and
should be possible to "reattach" the user to an existing session -
i.e. at most one session is allowed to exist at any given time. If we
passed the whole Subject to this method, the semantics of the method
could be the same (i.e. log me in as this user even if i don't know
the password) but we could implement the reattach scenario properly by
simply checking that given user's session is still active and "touch"
it or creating a new session for the subject if no valid session is
the "creator" of the resource is logged in temporarily in this
method - no problem as the "creator" is a Subject instance in the
-- OperationJob.getUserWithSession(Subject user, boolean reattach)
The purpose of this method is to get a user with a valid
session (obviously). This is done using the unauthenticated login.
If we reimplemented the loginUnauthenticated() method as described
above, we most probably wouldn't change the expected behaviour
of this method.
From the code analysis we can see that there is just a single problem with the
implementation and that is the possibility to reattach a Subject instance to a
session id that already existed for another Subject with the same username.
All analyzed code paths can be easily changed to avoid the need for such
behaviour and the only problem is that of the compatibility of "3rd party"
software relying on this behaviour when invoked remotely either using EJB or
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-426
Changing such that each login gets its own session and will not stomp on a user already logged in as that user.
The ability to "reattach" to an existing session for a user will go away because there will no longer be a single session associated with a username.
Historically a username shared an RHQ session (not the HTTP session, the
underlying RHQ session, the sessionId on the Subject). This had some mild
upside when it was convenient to share a session but has serious downside
as the logout of one gui session or cli job would invalidate the session
for any other gui or cli session using the same username.
So, this changes the behavior to make things behave more in line with what
folks hopefully expect. Each login gets its own RHQ session. Logout or
session timeout will not affect other logins.
One exception may be multiple sessions in the same browser, as there could
be conflict in cookie handling. This is not new and not a use case we are
planning to address.
In addition, I replaced some SubjectManagerLocal methods and supporting
queries with equivalent Criteria calls.
This seems stable.
Log in as the same user from various places, Browser1, Browser2, CLI, etc. When logging out one session the other sessions should remain unaffected.
Also, test other session issues from the browser. Ensure F5 refreshes work as expected. Also, session expiration (you'll need to wait an hour for the session to die automatically. Then, on subsequent login of the same user you should start where you left off).
verified by logging into RHQ from 2 different browsers on 2 different machines. logged in, logged out, navigated around. the browser sessions did not affect one another.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.