I was privy to another report of caching issues, posted in one of my groups:
I’ve noticed recently that my login will disappear fairly frequently — often when I click a link to another page within the CUNYMathBlog. For example, I notice (on the front page) that there are comments on the top story, so I click the “View Comments” button. On the subsequent page, I am no longer logged in (I noticed this because I wanted to leave a reply comment, but it requested my name/email/etc). I have replicated this on a number of pages (I log in, click on a link to another page on the commons, and it logs me out). I’ve tried it on both Chrome and Firefox on the Mac, and both give the same behaviour.
Given the other reports we've been having of similar behavior, I think we should investigate this further, and perhaps bring on others to consult (Cast Iron Coding?) if we can't solve it. Thoughts?
#3 Updated by Boone Gorges about 10 years ago
In order to investigate further, we will need more detailed reports of what's happening, and when, and to whom. Matt, as you suggest that you are sometimes a victim of the problem, can I ask you to take note of the following when it happens:
- What link had you just clicked?
- What page are you coming from?
- How long have you been logged into the Commons?
#4 Updated by Boone Gorges about 10 years ago
When I was working with this issue yesterday, I noticed that the Log In button in the toolbar was missing a redirect_to attribute, which was causing redirection funniness in some instances (including stubborn caches). https://github.com/castiron/cac/commit/4d5f95e6b27b050198801b7f2f86a751cc76427d may fix it. See also #1481
#7 Updated by Matt Gold about 10 years ago
A member just sent in the following report on some caching issues she experienced:
- What link had you just clicked? http://jitp.commons.gc.cuny.edu/about-the-journal/
- What page are you coming from? http://jitp.commons.gc.cuny.edu/
- How long have you been logged into the Commons? all day
- Browser/OS Firefox/Windows
(I was adding Cheryl Ball to the masthead)
#9 Updated by Matt Gold about 10 years ago
Not sure if this is a problem, but whenever, say, I edit a page or post in the dashboard, update that post, click on view site from the dashboard, then click on the link to the post I updated, the updates aren't there until I refresh. I've noticed this consistently on the commons, whereas on my own site these updates are immediately visible.
#10 Updated by Matt Gold about 10 years ago
Noticed the following problem with Steve in class yesterday, but it was on an outdated version of FF (not sure how outdated): logged into the homepage through the pop-up log-in box; after clicking "submit," the page still showed him as being in a non-logged-in state. Refreshing the page fixed the issue.
#11 Updated by Boone Gorges about 10 years ago
André, I'm adding you as a watcher to see if you have any ideas. Is there anything in our Apache configuration that would be causing unusually aggressive browser caching? Many of the examples of the problems listed above are happening during login, during which WP sends the following headers:
'Expires' => 'Wed, 11 Jan 1984 05:00:00 GMT', 'Last-Modified' => gmdate( 'D, d M Y H:i:s' ) . ' GMT', 'Cache-Control' => 'no-cache, must-revalidate, max-age=0', 'Pragma' => 'no-cache',
which is a very redundant way of saying "don't cache this"! Yet browsers are being stubborn on some setups, so I wonder if Apache is interfering.
#12 Updated by local admin about 10 years ago
Thanks for pulling me in, Boone. Interesting issue.
I think is quite plausible that server side caching parameters are playing a role in this case. I'll gladly help understand and solve the problem.
I guess the part I don't get is how would caxhing cause a user to be spontaneously logged out. I can see the scenario Matt reports here, where the browser cache isn't getting invalidated, but help me understand the logout piece please.
#13 Updated by Matt Gold about 10 years ago
I may be wrong (Boone will correct me if so), but I don't think the user is actually being logged out. Instead, what's happening is that the user logs in, but the page doesn't reflect that -- upon log-in, the user sees a cached page that makes it look like he/she never logged in. When the user refreshes the page, the logged in state correctly appears.
#14 Updated by Boone Gorges about 10 years ago
I may be wrong (Boone will correct me if so)
It's in my job description :-D
Matt is correct. The issue is not that users are being logged out - the WP/MW authorization cookies are intact. The problem is that the user gets served an out-of-date page. The fact that it happens only sporadically actually corroborates this: the only time that it's possible to see an unloggedin version of a page is when you recently visited that page while not logged in, but generally that only constitutes a small percentage of overall pages visited.
Unfortunately, I don't have any reliable steps-to-reproduce for you (I can't reproduce it myself, though I've seen it happen once or twice in my own browsing, generally on login). So for now, all I can really ask you to do is to have a look at the Apache config to see if there's anything that might be manipulating Cache-Control headers or anything like that. Thanks!
#15 Updated by Matt Gold about 10 years ago
It's in my job description :-D
If only you didn't take such pleasure in it!
(I can't reproduce it myself
André, Steve and I had this happen the other night in our classroom -- Room 7395. That computer is running an old version of Firefox, which would suggest that this was a browser issue if we hadn't received reports of problems from so many different browsers. But, at the least, heading up to that room and trying to log into the classroom computer might help you see what's happening.
#16 Updated by local admin about 10 years ago
- Status changed from Assigned to Reporter Feedback
- Assignee changed from Boone Gorges to local admin
Ok, I was able to reproduce the problem from my workstation itself:
1. Cleared my browser's cache.
2. Navigated to any arbitrary CAC page.
3. Logged in.
Result: top bar didn't change, reflecting my login status, until I refreshed.
Seems that the server configuration is indeed the problem here: the default browser cache expiration value sent out is access + two days.
I removed this configuration and restarted the server and the problem did not reoccur on testing.
I'm grabbing the ticket and setting it to reporter feedback. If you guys can help me test that problem went away I'll go ahead and close it.
#25 Updated by local admin about 10 years ago
You're welcome, Boone. I could have caught this earlier, so my bad.
Having said that, I reckon it would be cool to enable some caching (browser based or otherwise) for some of the static assets. What do you think? What's your sense of how snappy the site seems?