On Fri, 8 Sep 2006, Thomas Brüderli wrote:
Martin Marques wrote:
Besides the draft saving, could this also happen when deleting lots of mails, one at a time? Like hitting constantly the delete botton?
Could be. It actually can happen when there are concurrent requests and one of them gets a new cookie value. To prevent problems here, the "old" cookie will still be accepted as well in revision 338.
Doesn't this reopen the security problem related to autentication cookie?
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
Martin Marques wrote:
Could be. It actually can happen when there are concurrent requests and one of them gets a new cookie value. To prevent problems here, the "old" cookie will still be accepted as well in revision 338.
Doesn't this reopen the security problem related to autentication cookie?
Only a little. You can authenticate the session with the current auth cookie or with the last one. This helps, in case that two (almost) concurrent requests are sent to the server but the "old" cookie will not authenticate anymore 5 minutes later. We don't allow all "old" cookies just the last one.
~Thomas
On Fri, 8 Sep 2006, Thomas Bruederli wrote:
Martin Marques wrote:
Could be. It actually can happen when there are concurrent requests and one of them gets a new cookie value. To prevent problems here, the "old" cookie will still be accepted as well in revision 338.
Doesn't this reopen the security problem related to autentication cookie?
Only a little. You can authenticate the session with the current auth cookie or with the last one. This helps, in case that two (almost) concurrent requests are sent to the server but the "old" cookie will not authenticate anymore 5 minutes later. We don't allow all "old" cookies just the last one.
OK, but if the user hits 5 or 6 straight times the delete botton, then there will be more then 2 concurrent conexions (especially with bad network connections), which will make the third have problems with the expiration of the coookie. Or am I totally wrong?
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
Perhaps these actions should be batched. With Google Suggest they do not send a request for each key that is pressed. They start by timing how fast a request cycle takes to get to the server and back and then batch requests on that timing. If someone is taking several actions quickly in RC it could also batch those actions so this does not happen.
Does it not do that now?
Brennan
On Fri, 8 Sep 2006 11:56:09 -0300 (ART), Martin Marques martin@bugs.unl.edu.ar wrote:
On Fri, 8 Sep 2006, Thomas Bruederli wrote:
Martin Marques wrote:
Could be. It actually can happen when there are concurrent requests
and
one of them gets a new cookie value. To prevent problems here, the
"old"
cookie will still be accepted as well in revision 338.
Doesn't this reopen the security problem related to autentication
cookie?
Only a little. You can authenticate the session with the current auth cookie or with the last one. This helps, in case that two (almost) concurrent requests are sent to the server but the "old" cookie will not authenticate anymore 5 minutes later. We don't allow all "old" cookies just the last one.
OK, but if the user hits 5 or 6 straight times the delete botton, then there will be more then 2 concurrent conexions (especially with bad network connections), which will make the third have problems with the expiration of the coookie. Or am I totally wrong?
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador ---------------------------------------------------------)
-- Brennan Stehling Offwhite.net LLC brennan@offwhite.net
Martin Marques wrote:
OK, but if the user hits 5 or 6 straight times the delete botton, then there will be more then 2 concurrent conexions (especially with bad network connections), which will make the third have problems with the expiration of the coookie. Or am I totally wrong?
I guess, you got it wrong. The cookie doesn't change on every request but every 5 minutes. The new behavior just ensures that parallel requests, that are sent at a time where the cookie gets a new value, don't fail.
~Thomas
On Fri, 8 Sep 2006, Thomas Bruederli wrote:
Martin Marques wrote:
OK, but if the user hits 5 or 6 straight times the delete botton, then there will be more then 2 concurrent conexions (especially with bad network connections), which will make the third have problems with the expiration of the coookie. Or am I totally wrong?
I guess, you got it wrong. The cookie doesn't change on every request but every 5 minutes. The new behavior just ensures that parallel requests, that are sent at a time where the cookie gets a new value, don't fail.
OK, got it. My wrong. ;-)
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
-
Brennan Stehling -
Martin Marques -
Thomas Bruederli