id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
1484221,user can sometimes see someone else's message,kajtzu@…,,"In a office environment where there are several people sharing one physical PC and sharing one Windows login it seems that, when viewing a message another user has already viewed, other users will see the same email message. This seems to be relatively easily reproduceable at least with IE6 (6.02900.2180) on a large user base. I am not sure if the users close all their browser windows and really terminate IE or not. Also I have not tried this out on Safari or Firefox so far, just narrowing down the problem...

Network topology:
{{{
user - network - webmail
}}}

There are no proxies or transparent content caching devices including load-balancers in between. All traffic is SSL up to the webmail server.


I poked around the code and I think I figured out how the message is being called up when it is being double clicked; a GET is issued as follows:

{{{
GET /rcm/?_task=mail&_action=show&_uid=19&_mbox=INBOX HTTP/1.1
}}}
where _uid states what which message we want to see.

Looking at this with LiveHTTPHeaders and Firefox the operation (first part is sent towards the server, second part is what the server returned) the Expires is set 30 days into the future. Future requests for this URL really are not being fetched from the server by the browser (at least according to LiveHTTPHeaders).

{{{
GET /rcm/?_task=mail&_action=show&_uid=19&_mbox=INBOX HTTP/1.1
Host: www.bnsvcs.net
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://www.bnsvcs.net/rcm/?_task=mail&_mbox=INBOX
Cookie: sessauth=c51c8123e0d5038456080adddf301d6fd045a09f; sessid=lbvh5pogtbk6j6aue0ffr98j16

HTTP/1.x 200 OK
Date: Tue, 09 Jan 2007 19:23:26 GMT
Server: Apache
X-Powered-By: PHP/5.2.0
Expires: Thu, 08 Feb 2007 21:36:47 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 2967
Connection: close
Content-Type: text/html; charset=UTF-8
}}}

Is this on purpose? It seems this is a result of send_future_expiring_header() in program/steps/mail/show.inc:30. When removing the conditional and effectively applying send_nocaching_header() to everything the following happens:

{{{

HTTP/1.x 200 OK
Date: Tue, 09 Jan 2007 19:48:19 GMT
Server: Apache
X-Powered-By: PHP/5.2.0
Expires: Tue, 09 Jan 2007 19:48:19 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Tue, 09 Jan 2007 19:48:19 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 2967
Connection: close
Content-Type: text/html; charset=UTF-8
}}}

and the content is always being fetched from scratch. I was unable to replicate the issue anymore with IE6 but will know tomorrow if the fix is for real or if I need to continue chasing the problem.

This is with RHEL4 Apache 2.2.3, PHP 5.2.0, roundcube trunk.


Thanks.

",Bugs,closed,3,,Client Scripts,git-master,major,duplicate,caching,