The other day a user was replying to a particularly long email that
caused him to exceed the soft timeout limit of sqwebmail. When he
finally submitted the email to be sent he was instead redirected to
the expired.html form. When he clicked the back button he discovered
that since the newmsg window is the result of a POST IE, Mozilla, and
Netscape all prefer to rePOST the data rather than display the
pre-existing cached copy. He was a little upset that he had lost the
contents of the email and I admitted it wasn't necessarily the best
possible solution to a timeout.
In an effort to make sqwebmail handle timeouts a little more nicely I
applied the following small patch to my local copy of sqwebmail. All
it does is check whether the user is trying to send a message or save
a draft when the time out is noticed. If so, then a draft of the
current message is stored in the Drafts folder and the user is
redirected to the expired.html form.
The email is not sent, it is just stored in the drafts folder. I
thought this was a nice compromise between the security enforced by
soft timeouts and the annoyance of having long pieces of email get
lost in their entirety.
I can imagine that there are a few other circumstances in which a user
might like to have this behavior triggered: during spell checks or GPG
signing, perhaps. I don't really use those features myself so I can't
say.
I've been using the following patch for a few days and haven't had any
problems. I did some testing by setting the soft timeout ridiculously
low (i.e. 10 seconds) and it seems to work like I intend it to.
However, I'm not an expert with the source and it is possible I
overlooked some consideration or just don't understand how a
particular function is supposed to be used.
I realize that you can just up the soft timeout to some really large
value but that seems like it isn't really the right solution to this
problem...99% of the time I like having a meaningful soft timeout.
Just in the few cases where that number isn't quite big enough it
would be nice if sqwebmail's handling was a little more friendly from
the point of view of the end-user.
I would, of course, like to see this patch applied permanently to
sqwebmail (so I don't have to maintain it separately, not that it is
that difficult), so if anyone else likes this functionality please
speak up.
Justus
(BTW, the sqwebmail source is well written and easy to follow, kudos
to Sam for that. I wish more open source software were as easy to
read.)
--- /usr/src/sqwebmail/sqwebmail-3.1.0.20011006/sqwebmail/sqwebmail.c Thu Sep 27
02:15:08 2001
+++ sqwebmail.c Mon Oct 15 13:51:54 2001
@@ -1739,6 +1739,15 @@
|| last_time + timeoutsoft < current_time)
{
+ cgiformdatatempdir("tmp");
+ cgi_setup(); /* Read CGI environment */
+ if (*cgi("savedraft") || *cgi("sendmsg")) {
+ char* newmsg_createdraft (const char *curdraft);
+ char* p = newmsg_createdraft (cgi("draftmessage"));
+ if (!p) enomem();
+ free (p);
+ }
+
setgid(getgid());
setuid(getuid()); /* Drop root prevs */
chdir("/");
