|
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.
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. 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. 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. 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 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. The Entity Broker URL for this has been in trunk for a while (at least a couple months).
New version of patch that is i18n and has sakai.properties to disable/enable.
The current set of patches for this jira includes:
( 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 [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! [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.
Sorry, just didn't update/resolve it. This was finished and committed before the code freeze last week(s).
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.
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. ;) 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? 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.
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.
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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Major
Session Timeout Popup Utilizing Polling data from entity broker
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.