On Mon, Jul 14, 2003 at 04:13:46PM -0400, Jesse Guardiani wrote: > 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.
OK, that's more or less where I got to at the end. > > 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. I'm not sure exactly what security risk you're alluding to. Sessions are infinite if you tickle them at least once per timeout period, and what's being suggested is that the user would have to re-authenticate, which would effectively start a new session anyway. It's perhaps more of a confusion risk - accidentally sending a message you wrote 4 weeks ago but forgot about - but if you just redisplayed the page they were at, that wouldn't be so much of a problem. > > 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. I doubt users actually *type* 10 megs of stuff though. If you are attaching files, I guess that's another process - I really have not looked into how sqwebmail builds up a 'draft' message whilst allowing you to attach things. Regards, Brian.
