Created attachment 566824 [details] session_time_out Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install aeolus and click cloud resource provider 2. Leave it inactive for 15 mins minimum 3. After 15 mins , click on accounts , the url doesn't refresh and the page shown in attached screenshot is launched. Actual results: Expected results: Additional info: rpm -qa|grep aeolus aeolus-conductor-doc-0.8.0-39.el6.noarch aeolus-configure-2.5.0-16.el6.noarch rubygem-aeolus-image-0.3.0-10.el6.noarch aeolus-conductor-0.8.0-39.el6.noarch rubygem-aeolus-cli-0.3.0-12.el6.noarch aeolus-all-0.8.0-39.el6.noarch aeolus-conductor-daemons-0.8.0-39.el6.noarch
So.. this bug may be blocking automation.. and our ability to quickly qualify builds. There is another login issue that I will open up a bug on and paste here too
Note that there was much discussion the other day after the "session timeout" fix was pushed, and the consensus was that it was a new feature/enhancement, not a bugfix, so that it should not have been done. The fact that it's causing problems makes me think that the correct fix is to revert that bug, not to fix this issue. But that's just MHO.
Err, "revert that patch," not "revert that bug." Freudian slip.
(In reply to comment #2) > Note that there was much discussion the other day after the "session timeout" > fix was pushed, and the consensus was that it was a new feature/enhancement, > not a bugfix, so that it should not have been done. The fact that it's causing > problems makes me think that the correct fix is to revert that bug, not to fix > this issue. But that's just MHO. I'm fine either way.. I know in bug triage Hugh wanted the session timeout in. We can revisit the issue next triage
The correct behaviour when a user clicks on a link, after the session has timed out, is to load the login page, so that the user can authenticate for a new session.
Patch on list: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-March/009365.html Note that issue 799421 is tangentially related, in that it is also caused by 794536's introduction.
This has a patch posted, but it's out of scope for this release since the timeout has been reverted. Moving back to NEW and assigning to athomas as default assignee for now.
The correct behaviour, once a user has gone through the login page, is to take them to the page in the application which corresponds to the URL they originally clicked on, rather than to the usual landing page after login.
Can the patch mentioned above to applied easily to the tree?
This patch is now part of the patch adding session expiry, and does work. So this will be all set once the patch is ACKed and pushed.
Moving this to modified as it's apparently already done.
After Session time-out redirected to login-page and with valid credentials redirected to link user asked for. Verified on:- [root@dhcp201-113 ~]# rpm -qa|grep aeolus aeolus-conductor-doc-0.13.7-1.el6cf.noarch aeolus-all-0.13.7-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-0.13.7-1.el6cf.noarch aeolus-conductor-daemons-0.13.7-1.el6cf.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-1516.html