10

So it's the second time happening today. I enter the site and on the up-right other user's picture rep and badges appear. I clicked on it and it took me to his profile page, when on his page the up-right part with picture rep and badges turned to normal. It happened now and about 2 hours ago, and there were 2 different profiles. Why is this happening?

migrated from meta.stackoverflow.com Aug 6 '14 at 8:18

This question came from our discussion, support, and feature requests site for professional and enthusiast programmers.

  • 1
    Are you on a school or office network that includes a transparent caching proxy? – Martijn Pieters Aug 5 '14 at 10:10
  • I'm at the office but I don't know about the proxy. It's not the first time I access the site from work. – Alexandru Cimpanu Aug 5 '14 at 10:12
  • 4
    The other user may well be in your office too; if there is a transparent proxy that caches too much, you'll see pages cached that the other user visited recently. Vice versa, your pages are also going to be cached and shown to the other user. – Martijn Pieters Aug 5 '14 at 10:16
  • 7
    I'd switch to using https://stackoverflow.com while at the office to prevent this. – Martijn Pieters Aug 5 '14 at 10:18
  • Ok, it's just strange because I accessed the site every day for the last 2 months and haven't had this problem. – Alexandru Cimpanu Aug 5 '14 at 10:45
  • Perhaps that colleague has just started using Stack Overflow from the office? It could also be that a proxy was added further upstream, by the ISP used by your office, meaning that several companies (connections) are sharing that proxy. Either way, either the proxy is new, or the fact that someone else started using Stack Overflow through that same proxy. – Martijn Pieters Aug 5 '14 at 11:00
  • @AlexandruCimpanu is the other user from Romania as well ? Can you tell from his account ? Also, when the header loads up with his / hers profile info, are the messages in the achievements / inbox your or the other user's ? (asking cause i think they are loaded dynamically) – Catalin Deaconescu Aug 5 '14 at 11:42
  • @MartijnPieters then wouldn't it be a problem if under the same proxy a user can see the info for other users that use that proxy as well ? Shouldn't some of the page be generated dynamically depending on the user logged in (and his IP + cookies ) so you only get your data and nothing else ? Regardless of what is cached in proxies or not ? – Catalin Deaconescu Aug 5 '14 at 11:50
  • @CatalinDeaconescu: You can only advice proxies as to what to cache and what to ignore; a badly configured proxy can still ignore that information. – Martijn Pieters Aug 5 '14 at 11:51
  • @CatalinDeaconescu: yes, the dropdowns are AJAX requests, and the contents depend on your cookies (no user id is sent along in the URL) and the caching header is set to 'private'. – Martijn Pieters Aug 5 '14 at 11:53
  • @MartijnPieters I agree. But you can go around that by loading an empty 'template' page and adding data with ajax. And the ajax calls can be made to be unique so that they don't get cached. – Catalin Deaconescu Aug 5 '14 at 11:53
  • Also, I would add that this is likely a problem at Alexandru's office and not at an ISP level, as in Romania most companies have a dedicated IP and the ISP's don't add any proxy's. – Catalin Deaconescu Aug 5 '14 at 11:56
  • 2
    @CatalinDeaconescu: I am just leaving the possibility open; it depends onthe network arrangements; say the company is a university spin-off and still uses the university network connection, for example. – Martijn Pieters Aug 5 '14 at 11:58
  • 1
    If it happens, please also send us the full URL at which it is happening - just so I can check our cache configuration on that route. Normally, we only do server-side page caching for anonymous views, for all the obvious reasons. My guess is that this is a misconfigured proxy, but we can at least keep options open. – Marc Gravell Aug 5 '14 at 13:19
  • 1
    @DanNeely: yeah, a proxy that forces a man-in-the-middle re-wrapping of the SSL certificate with every browser in the network including the proxy certificate is such a wonderful idea for security. Cough, cough hack cough. – Martijn Pieters Aug 5 '14 at 14:54
7

One possible explanation, as noted by Martijn Pieters in the comments, is a badly posed Cache-Control header, which seems to be a side effect of using [OutputCache], even when we take pains to ensure that it doesn't cache for logged in users. I've had another stab at hacking our already hacked implementation, with the result that it should now continue to behave as normal for anonymous users, but logged in users will receive Cache-Control: private for these pages.

I cannot say for sure whether this was the actual cause, but it is consistent with what we would expect if an intermediate proxy decided to cache.

As side notes, note that the public header included no-cache="Set-Cookie", so this wouldn't have led to any cookie hijacking - and only applies to GET requests.

If you inspect this page now you should see this in action. I will deploy to the other sites after a brief stability check.

  • Confirmed that your cache control header now looks sane! – Martijn Pieters Aug 5 '14 at 20:04
  • As a historical note this used to (generally) be fine before because Vary was set to *, but now that it's just Accept-Encoding intermediate proxies were able to more liberally cache the response (though they sometimes incorrectly did with Vary: * too) – Tim Stone Aug 6 '14 at 12:22
  • @TimStone that's a red herring; that is because of the changes I made here; fixing that – Marc Gravell Aug 6 '14 at 12:45
  • Ah, so the response was being incorrectly cached in this case too. Hopefully they follow Cache-Control: private better than they followed the Vary: * exception. – Tim Stone Aug 6 '14 at 12:49
  • @TimStone the "Vary" thing looks like a bug in IIS; we're wrestling with it – Marc Gravell Aug 6 '14 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .