Brian Candler writes: > 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. >
I, and others here, have been "bitten" by the timeout while composing messages. (In fact, at another site where I installed Sqwebmail the soft timeout was set for hours because of that issue.) When the preview, send, or save buttons are clicked, the message is in the html request, so Jesse's method sounds like it would work to me. Brian, IMHO I don't see any need to retain any other pages that might have been in process. I can only think of Address Book, Preferrences, and Edit Mail Filters that would normally have any changes and those would be rare to have a timeout. George
