[SAK-13987] Session Timeout Popup Utilizing Polling data from entity broker Created: 16-Jul-2008  Updated: 30-Jun-2014  Resolved: 08-Oct-2008

Status: CLOSED
Project: Sakai
Component/s: Portal
Affects Version/s: 2.7.0
Fix Version/s: 2.6.0, 2.7.0

Type: Task Priority: Major
Reporter: Ryan Lowe (Inactive) Assignee: Matthew Jones
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File SAK-13987_portal.2008-09-26.diff     Text File SAK-13987_portal.diff.txt     Text File SAK-13987_portal.diff2.txt     Text File SAK-13987_reference.diff.txt    
Issue Links:
Depend
depends on SAK-13901 Entity Provider for Session Data CLOSED
Incorporate
incorporates SAK-8152 Sakai should warn a user before the u... CLOSED
Relate
relates to SAK-16162 session timeout causes continuous red... CLOSED
relates to SAK-16484 Session timeout poller inaccurately c... CLOSED
is related to SAK-18415 When not displaying users present the... CLOSED
is related to SAK-17106 [Session Timeout] Confusing UI Issues CLOSED
is related to SAK-18414 Clicking on the background on the por... CLOSED

 Description   

Create a session timeout alert box using the new SessionEntityProvider in entity broker from SAK-13901. With this, the JS app can poll the server for the current session information to see if the user's session has expired, or to see if it should show the DHTML popup or not. The added bonus of using entity broker is that the polling can happen without actually affecting the session and therefore keeping it alive.

This should be a highly accurate indicator of the current session state.



 Comments   
Comment by Ryan Lowe (Inactive) [ 01-Aug-2008 ]

Attached are patches to make the changes needed. Note, it takes pretty much trunk entitybroker at the time being to get the session entity object.

its fully functional, but not completely polished. It could use some internationalization and other styling work. It will, however, accurate display a pop up at 5 min left of your session and countdown accurately from there.

it works with multiple browser windows open at one time, since it actually asks the server what the status of your session is.

It only polls the server when it first expects your session to be timed out, and then once a minute as it counts down, so traffic is pretty light.

Comment by Ryan Lowe (Inactive) [ 01-Aug-2008 ]

Assigning to Megan

Comment by Megan May [ 13-Aug-2008 ]

Assigning to Michelle

Comment by Matthew Buckett [ 27-Aug-2008 ]

Aaron added another call to enity broker which allows you to just ask for the current session, rather than having to parse the session ID in the client.

Comment by Michelle Wagner [ 27-Aug-2008 ]

Assigning to Steve

Comment by Steven Githens (Inactive) [ 28-Aug-2008 ]

Updates for today. Needed to change variable name on the json session return from session.rightNow to session.currentTime to match EB nameing changes.

Work still needed:
1. Sakai property for time from logout to show alert dialog.
2. Turn dialog into proper markup/css with internationalization.
3. Not sure if we are using the proper way to register javascript functions at document ready. Currently using jQuery(document).ready
4. Use a better method to determine if user is logged in (currently we are looking at the DOM for a piece of markup that only occurs when logged in).
5. May need a property (or use an exisitng property) to determine URL to redirect to after being timed out.

Comment by Steven Githens (Inactive) [ 28-Aug-2008 ]

New version of the portal diff.

This jira now consists of 2 patches. The original standing patch for the reference module, and the diff2 patch for the portal module. The original portal.diff.txt is no longer valid.

Comment by sswinsb2@une.edu.au [ 29-Aug-2008 ]

Slight enhancement: Could the popup window include a countdown for the time left field, otherwise it stays on 1 minute (or whatever its set to) even though you might only have 1 second left.

It could countdown, then when expired, it could say, 'Session Expired', then fade the popup out to the logged out Gateway.

Comment by Ian Boston [ 25-Sep-2008 ]

I have reviewed the patch and it looks Ok, however I have one concern that IIMHO needs to be answered before its applied.
I cant see that

a) Its disabled by default.
b) It can be enabled by a change to sakai.properties

c) Also, It mentions a direct url in entity broker. Is that already applied to trunk ?

If you can address a) and b) and clear c), then I am happy to apply.

Thanks

Comment by Steven Githens (Inactive) [ 26-Sep-2008 ]

Actually there are a few more things involved detailed on the proposal page:

http://confluence.sakaiproject.org/confluence/display/MGT/Session+Time-Out+Alert

There is also a property to set the warning time size before the page times out, as well as a i18n version of the warning dialog that is a velocity template.

The patches above are a bit old, but will make another set hopefully at the end of today.

Comment by Steven Githens (Inactive) [ 26-Sep-2008 ]

The Entity Broker URL for this has been in trunk for a while (at least a couple months).

Comment by Steven Githens (Inactive) [ 26-Sep-2008 ]

New version of patch that is i18n and has sakai.properties to disable/enable.

Comment by Steven Githens (Inactive) [ 26-Sep-2008 ]

The current set of patches for this jira includes:

SAK-13987_portal.2008-09-26.diff
SAK-13987_reference.diff.txt

( I can't delete the other ones ).

This solves the issue of:
1) Making the functionalbity disabled by default
2) The dialog being i18n.

A charon portal handler was added to:
1) Determine whether the functionality is disabled, and the amount of warning that should be given to the user before the dialog. This is checked via a cached ajax query.
2) A Velocity template for the warning dialog that includes 2 i18n strings.

The new sakai.properties are:
timeoutDialogEnabled
timeoutDialogWarningSeconds

The default is false, so if the enabled property is missing the functionality will be disabled.

The new i18n strings are:
timeout_dialog_warning_message
timeout_dialog_keepalive

Comment by Peter A. Knoop [ 29-Sep-2008 ]

[Bulk Comment] This Task (or Sub-Task) issue currently is Unresolved, but has a Fix Version of 2.6. The Code Freeze for Sakai 2.6 has now passed (29-Sep-2008, 8:00am Eastern US time).

If you are still working to resolve this issue for 2.6, then please post an email to sakai-dev to let everyone now that you need an exception for this JIra, explain what is left to do, and when you plan to have the work completed; please include that information here in the Jira as well.

Otherwise, if the resolution of this task has been postponed, please reset the Fix Version to 2.7 or Unknown, depending on what you're new expectations for completion are. If the issue is no longer relevant, please close the issue as Won't Fix or Incomplete with an explanation of why.

Thanks!

Comment by Peter A. Knoop [ 08-Oct-2008 ]

[Bulk Comment] The fix version for this Unresolved Tasks still indicates 2.6, but the code freeze is well passed now, and no exception was requested for this work. The Fix Version of this issue is being reset to 2.7, with the expectation that you are planning to finish the work in time for that release. If that is not the case, please update the Fix Version appropriately, or if you are not actively working on this issue, consider turning it into a Feature Request.

Comment by Steven Githens (Inactive) [ 08-Oct-2008 ]

Sorry, just didn't update/resolve it. This was finished and committed before the code freeze last week(s).

Comment by Steven Githens (Inactive) [ 08-Oct-2008 ]

This work was finished the Friday before code freeze, permission was obtained from the module owners, and it was committed Sunday before the Monday deadline.

Comment by Matthew Jones [ 23-Mar-2009 ]

Three comments:

  • Currently sakai 2.5 (and I believe 2.6) is stuck on jquery 1.1.4 which doesn't support the ajax cache parameter. This results in the lastaccessed time being cached and this portal timer never gets updated or set. I needed to modify the line in portalscripts.js

url: "/direct/session/" + sessionId + ".json?auto=true"
to be
url: "/direct/session/" + sessionId + ".json?auto=true&_=" + (new Date()).getTime();

(As this is what jquery 1.2.1 does for the cache parameter)

  • The regular expression that gets the sessionId didn't seem to be always working for me. It seems like this value can just be changed to "current" in the url: string anyway as the entitybroker knows what the current session is. Either that or rewrite the regex to be a little more specific. (JSESSIONID=(\w {8}

    (?:-\w

    {4}

    )

    {3}

    -\w

    {12}

    ) ?

  • Lastly, if you have any local skin overrides for your installation you'll might have to add the .css changes to your local skin for it to pick up. This should have been obvious but I couldn't figure out why the timer was popping up on the bottom of the screen.
Comment by Branden Visser [ 27-Mar-2009 ]

I'd consider re-opening this ticket because of Matthew's comment about the regex. It seems that if there is more than 1 cookie for the domain (our hardware load-balancer sticks some extra cookies onto the domain for sticky-sessions), then the regex will not work if the Sakai cookie (JSESSIONID) is not the first cookie in the list. Hardcoding the cookie name to fix the regex is not a desirable alternate solution either simply because it may be changed at the app server.

Finally, one request: We would like to merge this for our 2.5 instance. The changes done so far merge nicely into 2.5, but it seems the only thing missing in 2.5 is the handling of the /direct/session requests. Does anyone know of any merges I can do that will provide the minimal entity broker functionality to support this in 2.5?

Comment by Peter A. Knoop [ 15-Apr-2009 ]

Branden, I'd suggest posting the question in your comment out to the sakai-dev list, so that a broader audience sees it and might be able to respond with details.

Comment by Charles Hedrick [ 23-Apr-2009 ]

Brandon is right. After turning on the warning and applying the fix to add new Date our system went into a continuous redirect loop for some users. The problem was JSESSIONID not being the first cookie. This failure mode is so drastic that either this issue needs to be addressed, or sites need to be warned that enabling this feature has a reasonable probability of making the system unusable by some users.

Comment by Peter A. Knoop [ 23-Apr-2009 ]

Matt/Branden/Charles – if you think you've found a bug with this feature, could you please capture that to a new Jira? This one tracked the implementing of the feature, and the svn logs confirm it will be in the 2.6.0 release. So, if there are problems with it, then please report them as Bugs. Thanks.

Comment by Anthony Whyte [ 16-Oct-2009 ]

In 2.6.0.

Generated at Sun Sep 22 10:17:02 CDT 2019 using Jira 8.0.3#800011-sha1:073e8b433c2c0e389c609c14a045ffa7abaca10d.