On Mon, Jul 14, 2003 at 02:55:33PM -0400, Jesse Guardiani wrote: > Basically, my idea is to simply save the contents of the > POST request (or GET request) to a file in the user's > home directory _IF_ the hard timeout has _NOT_ been > exceeded, but the soft-timeout _HAS_ been exceeded. > Let's call this file ".sqwebmail-saved" for the sake of > discussion. > > We then display a special "Login to Resume Session" > page. Let's call this page resume.html for the sake of > discussion. > > Anytime a user logs in with the login.html, expired.html, > or invalid.html page we delete ".sqwebmail-saved". We > could also delete this file after the hard timeout from the > clean cache perl script. > > But, if the user logs in using the new resume.html page, > AND their session's hard-timeout has NOT been exceeded, > we take the data from the .sqwebmail-saved file and use > it to replace all current CGI GET and POST data. > > Sounds pretty simple to me. What thinks the list?
Well, I have been bitten by the 20 minute soft timeout before, so I just set it up to an hour. What do other webmail systems do if you take that long to write a message? HTTP is stateless, so every POST has to be authenticated separately (this is optimised by use of a cookie) and of course this has to be done at the start of processing each request. When a user is composing a message, the data exists entirely in the client's browser until they click "send", "preview" etc. So what I think you're saying is: if the login has expired then kick back to the login page, UNLESS they're trying to do "send" or "preview" operations, IN WHICH CASE check if their login has soft-expired and not hard expired. In that case take them back to a new login screen (call it "resume.html") whilst saving the message body to sqwebmail-saved; if/when they successfully login they can continue with the original operation (presumably you would just put them straight back into the message compose page? Or put the message into the Drafts folder?) Since the user is properly reauthenticating at resume.html, I don't see why this shouldn't work even if they are past their hard timeout... but otherwise you're giving the impression that there are two different soft timeouts, one for message browsing, and one for composing, except exceeding the composing soft timeout requires a second authentication to continue the session. It all just seems rather complicated to me. A more general mechanism (but still complicated) would be to allow *any* session to be resumed: if a login has expired, take the POST data and store it all in a temporary field on the login screen. Then, when the user successfully authenticates, process the contents of this field as the original request, instead of going to the default folder-contents page. Regards, Brian.
