[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Sessions] Agreed points from 5/25 telecon
This discussion has been dead for a bit (seeing as I am working on a Sessions presentation) I need to breath some life back into it. -----Original Message----- From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] Sent: Thursday, May 31, 2001 3:38 PM To: security-services@lists.oasis-open.org Subject: [Sessions] Agreed points from 5/25 telecon [stuff deleted] If the local timeout is shorter than the global, then when a user times out locally they are logged out locally. If the user returns before the global timeout, they will presumably present a ticket and things will proceed just as if the user had never been to that site before. Although this is certainly a valid way of operating it bothers me that, as an ASP developer, there would be no way for me to defer the local timeout-induced-logout based on the fact that the global session is still active (if I so chose). The reason for doing this is that I don't want to lose the user's local session state, but I also do not want to have to write a bunch of extra code to save the user's state on timeout and restore the user's when they return. Imagine working with some application and entering data for 20 minutes, being pulled away to some other application for 30 minutes, then coming back to find your 20 minutes of work flushed down the drain because, to the first application, it looks like you timed out then logged back in again. I think one of the services the Session Authority should provide is to answers questions like "To the best of your knowledge, is global session XYZ sill active?". Individual applications can make use of this service as they see fit, but they are not required to. If the local timeout is longer, the participant site will simply ignore the global logout and perform local timeout. Essentailly this is a variant on ignoring the global logout and continuing until the assertions expire. I don't really see the usefulness of distinguishing based on the relative lengths of the local and global timeouts. If the local timeout is larger than the global timeout, it is still possible that the user could be busy with some other session participant at intervals that are always less than the global timeout, but together are greater than the local timeout. W/respect to my comments above, I may still want to keep a local session open if I know that the user is busy somewhere in the system.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC