Project

General

Profile

Actions

Bug #1657

closed

Caching Issues

Added by Matt Gold about 12 years ago. Updated about 12 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
-
Category name:
BuddyPress (misc)
Target version:
Start date:
2012-02-26
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

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?

Actions #1

Updated by Boone Gorges about 12 years ago

bring on others to consult (Cast Iron Coding?) if we can't solve it. Thoughts?

Ye of little faith

Actions #2

Updated by Matt Gold about 12 years ago

Game on.

Actions #3

Updated by Boone Gorges about 12 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?
- Browser/OS

Actions #4

Updated by Boone Gorges about 12 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

Actions #5

Updated by Matt Gold about 12 years ago

Hi Boone,

I'll definitely keep track of future occurrences. I'll also reach out to others I know have been affected by this to try to document this -- though it would be amazing if you have already found and fixed the error!

Matt

Actions #6

Updated by Matt Gold about 12 years ago

Just want to say that my instinct is that you may have caught the error, since most of the issues I've heard about did indeed happen right at the point of log-in. Fingers crossed.

Actions #7

Updated by Matt Gold about 12 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)

Actions #8

Updated by Boone Gorges about 12 years ago

What exactly is the issue? That the user seemed logged out?

Actions #9

Updated by Matt Gold about 12 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.

Actions #10

Updated by Matt Gold about 12 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.

Actions #11

Updated by Boone Gorges about 12 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.

Actions #12

Updated by local admin about 12 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.

Actions #13

Updated by Matt Gold about 12 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.

Actions #14

Updated by Boone Gorges about 12 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!

Actions #15

Updated by Matt Gold about 12 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.

Actions #16

Updated by local admin about 12 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.

Actions #17

Updated by Matt Gold about 12 years ago

Wow -- it would be excellent if we've found the problem!! Will check in with a few others to confirm that this is fixed. Thanks, André!

Actions #18

Updated by Matt Gold about 12 years ago

I asked three people who have experienced this issue previously to let me know whether they are still encountering it.

Reporter #1: "Yes, I think the problem is gone."

Still waiting on the others, but this is promising.

Actions #19

Updated by local admin about 12 years ago

You're quite welcome! My apologies for not catching this earlier.

Thanks for checking with the reporters, Matt.

Actions #20

Updated by Boone Gorges about 12 years ago

  • Target version changed from 1.3.9 to 1.3.10
Actions #21

Updated by local admin about 12 years ago

ping

Actions #22

Updated by Matt Gold about 12 years ago

  • Status changed from Reporter Feedback to Resolved

I haven't heard anything, so I'm fine with closing the ticket.

Actions #23

Updated by local admin about 12 years ago

Cool, thanks. Later we should probably revisit caching at least static assets (images, javascripts, stylesheets), as right now users pretty much make a new request each time.

Actions #24

Updated by Boone Gorges about 12 years ago

When this ticket was transferred away from me, I stopped getting updates, so pardon my lateness - but thanks very much, André! Glad we could uncover the issue.

Actions #25

Updated by local admin about 12 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?

Actions

Also available in: Atom PDF