Description of problem: I opened the webadmin portal more than 5 hours. There was no any operation on the website during the 5 hours. And it supposed to be log out automatically if i didn't operate on the website for 30 minitues.(the value of UserSessionTimeOutInterval is 30) Web browser: Chrome 39.0.2171.65(64-bit) By the way the session timeout function works well when i use oVirt 3.3. Version-Release number of selected component (if applicable): 3.5.0.1-1 How reproducible: Always Steps to Reproduce: 1.Log in the webadmin portal 2.Just keep the website open, do not operate on the website for 1 hour Actual results: The session did not timeout Expected results: The session timed out Additional info: I checked the bug list and found the same bug for Version 3.1, but i don't know how to reopen it, so i submit a new one.
as far as I understand as long the ui is opened then the session is being refreshed. but I may be wrong.
Any UI plugins installed?
(In reply to Alon Bar-Lev from comment #1) > as far as I understand as long the ui is opened then the session is being > refreshed. but I may be wrong. "idle" ui should result eventually in a session time-out; all queries that running in the background periodically (e.g. queries to refresh the view of the main tab grid) are not supposed to "count" as ones that are keeping the session alive (this is what the VdcQueryParametersBase.get/setRefresh() property is for). (In reply to Yair Zaslavsky from comment #2) > Any UI plugins installed? I am not sure if ui-plugins would affect anything, assuming this BZ was reported on an ovirt version that doesn't include http://gerrit.ovirt.org/#/c/35185/. If it does include http://gerrit.ovirt.org/#/c/35185/, it may be a different story, because since this patch - engine session is shared between the ui and ui-plugins. @Alon - any reason that this is assigned to Yair, given that this is a ux issue?
(In reply to Einav Cohen from comment #3) > @Alon - any reason that this is assigned to Yair, given that this is a ux > issue? I thought that session data container handling is infra as we almost rewrote it within the aaa efforts, please feel free to reassign :)
(In reply to Alon Bar-Lev from comment #4) > (In reply to Einav Cohen from comment #3) > > @Alon - any reason that this is assigned to Yair, given that this is a ux > > issue? > > I thought that session data container handling is infra ... it is probably 'infra', however you are the one that set the Whiteboard to 'ux'... I actually don't know whether this is an infra issue (i.e. something on the server side possibly due to the AAA changes) or a ux issue (i.e. there is some periodical query invoked by the client that has 'VdcQueryParametersBase.setRefresh(true)' by mistake). if you think that it is most likely an infra issue and that the infra team should take care of the initial investigation, please keep it assigned to Yair but change Whiteboard to 'infra'. if you would like the ux team to do the initial investigation - I can assign it to someone from my team, just let me know.
(In reply to Yair Zaslavsky from comment #2) > Any UI plugins installed? I installed the ovirt-optimizer plugin in one environment, but another environment which had no any plugin also has the same problem.
(In reply to Einav Cohen from comment #5) > (In reply to Alon Bar-Lev from comment #4) > > (In reply to Einav Cohen from comment #3) > > > @Alon - any reason that this is assigned to Yair, given that this is a ux > > > issue? > > > > I thought that session data container handling is infra ... > > it is probably 'infra', however you are the one that set the Whiteboard to > 'ux'... > > I actually don't know whether this is an infra issue (i.e. something on the > server side possibly due to the AAA changes) or a ux issue (i.e. there is > some periodical query invoked by the client that has > 'VdcQueryParametersBase.setRefresh(true)' by mistake). > > if you think that it is most likely an infra issue and that the infra team > should take care of the initial investigation, please keep it assigned to > Yair but change Whiteboard to 'infra'. > > if you would like the ux team to do the initial investigation - I can assign > it to someone from my team, just let me know. Why sould we want to set refresh anyway from UI? I see VdcQueryParametersBase by default has refresh set to true.
(In reply to Yair Zaslavsky from comment #7) > Why sould we want to set refresh anyway from UI? we want to make sure that if the ui is idle, i.e. no user interaction is being done, the session will eventually time-out. so, for example, when a user is moving from one main tab to another (e.g. VMs to Hosts) - that's user interaction. so the first "Hosts:" search query (that we will invoke as a result of now being in the Hosts main tab) will be invoked with 'refresh = true', to make sure that the query will "count" as one that is keeping the session alive; any consequent calls to the "Hosts:" search query will happen as a result of the automatic periodical refresh that the GUI is doing in the background, and not as a result of user interaction; so from the user's perspective, the GUI is 'idle'; therefore, all of these consequent "Hosts:" search queries will be invoked with 'refresh = false'. if no additional user-interaction will occur, all "background" queries will continue to be sent to the backend with 'refresh = false', resulting eventually in the engine session timing-out and the GUI automatically logging out. > I see VdcQueryParametersBase by default has refresh set to true. and, as explained above, we sometimes need it to be 'false' - that's why "we want to set refresh from UI".
*** Bug 1172726 has been marked as a duplicate of this bug. ***
Given that this issue occurs on env. with no UI plugins installed (see comment 6), this is most probably the same issue as bug 1172726 -> UI plugin infra's REST heartbeat mechanism prevents Engine session from timing out.
oVirt 3.5.1 has been released and since this bug is targeted 3.5.1 and in modified state, it should be included in this release. Please re-target and move nack to modified if this assumption is not valid for this bug.
this ovirt bug was fixed during 3.5.1 cycle and is included in the build, and therefore should be verified.
Verified downstream in rhevm-3.5.1-0.1.el6ev (vt14), with RH support UI plugin installed (redhat-support-plugin-rhev-3.5.0-1.el6ev). Clients: - firefox-31.5.0-1.el6_6.x86_64 ESR - firefox_36.0.1+build2-0ubuntu0.14.04.1_amd64 Verification steps: 1) On engine, set user session timeout to 5 minutes: # engine-config -s UserSessionTimeOutInterval=5 && service ovirt-engine restart 2) On client, open Webadmin portal, log in and then do no actions in webUI. 3) Wait 5-6 minutes. Result: After 5 minutes, the user session expires and user is redirected to login page.
This is an automated message. oVirt 3.5.4 has been released on September 3rd 2015 and should include the fix for this BZ. Moving to closed current release.