Bug 857438 - Create a way to let GUI session timeout be configurable
Create a way to let GUI session timeout be configurable
Product: JBoss Operations Network
Classification: JBoss
Component: UI (Show other bugs)
JON 3.1.0
All All
unspecified Severity medium
: ER01
: JON 3.2.0
Assigned To: Jirka Kremser
Mike Foley
: FutureFeature
: RHQ-2082 JON3-32 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-09-14 08:38 EDT by Rafael Chies
Modified: 2015-03-18 13:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-02 15:43:29 EST
Type: Feature Request
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rafael Chies 2012-09-14 08:38:05 EDT
There are a lot of customers (at least here, in Brazil) that use JON in a NOC environment. For these environments, they need to keep some JON Dashboard all day logged in, and displayed in some big screen. However, the user session timeout on JON does not allow the wish "all day logged in". Nowadays we have to log in every time the timeout happens.

It would be great if we could configure the session timeout. Maybe, after a user login in the GUI, we could choose in a checkbox if we want to keep the session without timeout, maybe using a keepalive control with the server.

By the way, I have just talked with Mike Thompson about that new feature.

Thanks in advance !
Comment 1 Jirka Kremser 2013-04-09 11:40:11 EDT
There are 3 possible ways to go:

1) To provide the same behavior for all RHQ nodes withing the RHQ cluster. I.e. to have a possibility to change the value of the session timeout in the system settings.

2) To have the same session timeout for one RHQ server. The value would be stored in the rhq-server.properties file => no UI change

3) And the finest graded - to allow each user to set its own value and store it in the user's prefs. This would require a new UI for editing it. Perhaps some parts of test page could be reused.

Also there are two ways of implementing the change propagation. In other words, what happens if someone changes the value. Should the change be considered after next login (a) or immediately (b)?

I've made a prototype using the "1a" approach (using sys. settings and change happens after next login).

The default value and at the same time the smallest possible value is 1 hour and it is unbounded (if an extra large value is typed in, it is set to 24 days (this is what Integer.MAX_VALUE of milliseconds is))

The another story is the testability. Most of the logic is in the UserSessionManager (coregui), so it is not testable by our integration tests. What can be used is the sahi.

Since the minimal value is 1 hour, it is a bad idea to wait 1 hour and sahi has no means to fake the value in the db to be some lover value(in the db, the duration is stored as milliseconds). Perhaps the GWT Arquillian extension [1] could be used for this purpose. Simple GWT unit tests won't work because we need a little bit of contextual information there.

[1] http://arquillian.org/blog/2013/02/26/arquillian-extension-gwt-1-0-0-Alpha1/
Comment 2 Jirka Kremser 2013-04-10 08:27:21 EDT
master 334d2167e

I was manually testing it also for JSF charts
Comment 3 Jay Shaughnessy 2013-04-10 17:37:32 EDT
commit 5cb483d45cfd88ec6ad61e1c8dfb31126e572ed5
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Wed Apr 10 16:51:51 2013 -0400

    Add a dbupgrade step for this. schema now at 2.132.  Also, add a little
    more protection when setting the session timeout.
Comment 4 Larry O'Leary 2013-09-06 10:33:50 EDT
As this is MODIFIED or ON_QA, setting milestone to ER1.
Comment 5 Larry O'Leary 2013-09-06 10:34:29 EDT
As this is MODIFIED or ON_QA, setting milestone to ER01.
Comment 6 Jirka Kremser 2014-03-04 08:37:52 EST
*** Bug 535380 has been marked as a duplicate of this bug. ***
Comment 7 Jirka Kremser 2014-03-04 08:39:59 EST
*** Bug 1070248 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.