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?

24
  • 1
    Are you on a school or office network that includes a transparent caching proxy? Aug 5, 2014 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. Aug 5, 2014 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. Aug 5, 2014 at 10:16
  • 7
    I'd switch to using https://stackoverflow.com while at the office to prevent this. Aug 5, 2014 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. Aug 5, 2014 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. Aug 5, 2014 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) Aug 5, 2014 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 ? Aug 5, 2014 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. Aug 5, 2014 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'. Aug 5, 2014 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. Aug 5, 2014 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. Aug 5, 2014 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. Aug 5, 2014 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. Aug 5, 2014 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. Aug 5, 2014 at 14:54

1 Answer 1

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.

5
  • Confirmed that your cache control header now looks sane! Aug 5, 2014 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, 2014 at 12:22
  • @TimStone that's a red herring; that is because of the changes I made here; fixing that Aug 6, 2014 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, 2014 at 12:49
  • @TimStone the "Vary" thing looks like a bug in IIS; we're wrestling with it Aug 6, 2014 at 16:00

You must log in to answer this question.

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