Red Hat Bugzilla – Full Text Bug Listing
|Summary:||session oddities when the same user is logged in from multiple machines|
|Product:||[Other] RHQ Project||Reporter:||Joseph Marques <jmarques>|
|Component:||Core UI||Assignee:||Jay Shaughnessy <jshaughn>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||0.1||CC:||ccrouch, cwelton, jshaughn|
|Fixed In Version:||4.1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-02 03:24:02 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||705059, 715334|
Description Joseph Marques 2008-05-02 13:30:00 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.
Comment 1 Heiko W. Rupp 2008-06-07 15:19:54 EDT
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.
Comment 2 Joseph Marques 2008-07-02 07:19:07 EDT
work around for now is to only have a user login once at a time. will push to 2.0 for further consideration.
Comment 3 John Mazzitelli 2009-05-28 09:07:15 EDT
from lukas - he did some research and here's what he found: --- Problem ------- 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? Code analysis ------------- The offending method that causes our problems is SessionManager.getSessionIdFromUsername(String). This method is unfortunately called from a number of places (excluding tests): SubjectManagerBean -- 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 behaviour? 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? -- EditPasswordAction.execute() relogin -- RegisterAction.execute() login of the newly registered user -- AuthenticateUserAction.execute() 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 present. -- DiscoveryBean.addResource() loginUnauthenticated(username, true) the "creator" of the resource is logged in temporarily in this method - no problem as the "creator" is a Subject instance in the method body. -- 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. -- GroupOperationJob.execute() getUserWithSession(user, false) -- ResourceOperationJob.execute() getUserWithSession(user, false) -- ResourceOperationJob.invokeOperationOnResource() getUserWithSession(user, true) Conclusion ---------- 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 WS.
Comment 4 Red Hat Bugzilla 2009-11-10 16:09:02 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-426
Comment 6 Jay Shaughnessy 2011-05-17 15:19:05 EDT
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.
Comment 7 Jay Shaughnessy 2011-05-19 09:59:31 EDT
primary work: commit 07471e1f014eed497b43cafeddaffa1cabc873c1 addendum fix: commit fa3cb7852df40c0bfbb49fa6f40ae4d6cb8f82f6 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.
Comment 8 Jay Shaughnessy 2011-05-23 11:42:35 EDT
This seems stable. Test Notes: 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).
Comment 9 Mike Foley 2011-05-24 13:50:35 EDT
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.
Comment 10 Heiko W. Rupp 2013-09-02 03:24:02 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.