On Monday 14 July 2003 15:57, Brian Candler wrote: > 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?
I've seen a few do what I'm describing. They allow you to log back in and complete whatever operation you were working on. > > 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, Actually, that isn't quite what I was suggesting. I was actually suggesting that as long as the hard timeout hasn't expired we always kick back to the resume.html page and save whatever POST or GET data the user was attempting to submit before they realized their session timed out. If/When the user logs back in from resume.html we then strip out all GET and POST data in memory and replace it with the contents of sqwebmail-save. Does that make sense? However, you've made me realize that this isn't ideal. The user will likely want to see the Create Message dialog rather than see "Your message has been successfully sent". So my revised idea would be to plug the values stored in sqwebmail-saved BACK into whatever form the user attempted to submit before they realized their session was timed out, and redisplay the form. I think this is much more appropriate. What do you think? > 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... Because if the user is past their session's hard timeout we will automatically delete sqwebmail-saved. You have to have some sort of hard timeout, otherwise sessions would be rather infinite, which is a security risk. > 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. No I'm not. Their is still a soft timeout and a hard timeout, only now the hard timeout is more tangible to the user. If the user exceeds their hard timeout, they're done. Session over. No more resume. Make sense? > > It all just seems rather complicated to me. I'm sorry. > > A more general mechanism (but still complicated) would be to allow *any* > session to be resumed: If you mean: "allow *any* session to be resumed indefinately" then I think that is a security risk. If you mean: "allow sessions to be resumed regardless of current <form>" then I agree. I think that would be ideal. > if a login has expired, take the POST data and store > it all in a temporary field on the login screen. Yes, but then if the user just submitted a 10 Meg message he/she would have to transfer that message from the server to the browser and from the browser to the server before logging back in. This is why I suggest the sqwebmail-saved file. > 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. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net
