9 messages in net.sourceforge.lists.courier-sqwebmailRe: [sqwebmail] Sqwebmail bug?
FromSent OnAttachments
EndaJul 2, 2008 1:58 pm 
Sam VarshavchikJul 2, 2008 3:22 pm 
EndaJul 2, 2008 3:45 pm 
Sam VarshavchikJul 2, 2008 4:31 pm 
Roger B.A. KloreseJul 2, 2008 6:24 pm 
EndaJul 3, 2008 12:02 am 
Enda CronnollyJul 3, 2008 12:11 am 
Sam VarshavchikJul 3, 2008 4:02 am 
EndaJul 3, 2008 7:08 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [sqwebmail] Sqwebmail bug?Actions...
From:Roger B.A. Klorese (rog@queernet.org)
Date:Jul 2, 2008 6:24:47 pm
List:net.sourceforge.lists.courier-sqwebmail

Enda wrote:

That's exactly how it should work. HTTP is a stateless protocol. There is no mechanism by which a web server can possibly detect that you have closed your web browser. Therefore, if a login request is received fro a different machine, the choices are:

1) To terminate the older login, and accept the new one.

2) To refuse the new login request until a lengthy timeout period has expired, without receiving any HTTP request for the active login session. If your PC crashed, you had to reboot, and were assigned a new IP address by your Internet provider -- tough luck, wait a few hours before you can read your webmail again.

So, which one makes more sense to you?

Yes Sam, you're spot on there, and made the correct design choice. The problem lay in my interpretation of your text.

But that's not what those words mean to the likely naive user. "Disconnect other sessions for this user, if active" means what you intend. "Restrict access" seems to mean not to allow access to another IP address AFTER THIS LOGIN.