Login rejected on cached pages

I can confirm that

Which version of Drupal? If 7.2, I'm going to scream, since this has worked fine since Drupal 5.

Are you using core caching or an external mode (like varnish)?

What is in {cache_page}, especially, what cache_ids?

This came up before -- see #1046844: domain_bootstrap breaks page cache -- and so if that behavior has changed...

I cannot replicate this report in the browser.

@andros

Did you confirm this error when running curl?

If not, what browsers? I'm testing on FireFox 4 and Chrome 12 (Max OS 10.6) with no issues.

As logged in (user 1), with a valid matching page in cache.

Firefox: user 1

Cache-Control:no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Type:text/html; charset=utf-8
Date:Fri, 17 Jun 2011 19:15:11 GMT
Etag:"1308338111"
Expires:Sun, 19 Nov 1978 05:00:00 GMT
Keep-Alive:timeout=15, max=99
Last-Modified:Fri, 17 Jun 2011 19:15:11 +0000
Server:Apache/2.0.63 (Unix) PHP/5.3.2 DAV/2
Transfer-Encoding:chunked
X-Generator:Drupal 7 (http://drupal.org)
X-Powered-By:PHP/5.3.2


Chrome: user 2
Cache-Control:no-cache, must-revalidate, post-check=0, pre-check=0
Connection:Keep-Alive
Content-Type:text/html; charset=utf-8
Date:Fri, 17 Jun 2011 19:17:10 GMT
ETag:"1308338230"
Expires:Sun, 19 Nov 1978 05:00:00 GMT
Keep-Alive:timeout=15, max=100
Last-Modified:Fri, 17 Jun 2011 19:17:10 +0000
Server:Apache/2.0.63 (Unix) PHP/5.3.2 DAV/2
Transfer-Encoding:chunked
X-Drupal-Cache:MISS
X-Generator:Drupal 7 (http://drupal.org)
X-Powered-By:PHP/5.3.2

Chrome: logged out

Cache-Control:public, max-age=0
Connection:Keep-Alive
Date:Fri, 17 Jun 2011 19:18:17 GMT
Etag:"1308337690-1"
Keep-Alive:timeout=15, max=99
Server:Apache/2.0.63 (Unix) PHP/5.3.2 DAV/2

OK, just replicated.

/me curses Drupal 7.2

Bumping.

The steps in #10 work in Chrome to replicate the bug.

More accurate title.

Note that this does not appear to happen to user 1.

EDIT: This is actually browser-specific. FireFox 4 doesn't have this problem.

AND it doesn't happen in FireFox. But it does in Safari and Chrome.

Commenting out drupal_settings_initialize() in domain.bootstrap.inc solves this problem, but probably causes others.

At least that points us to the right place.

Patch for 7.x.2.

This does what I tried to avoid in the first place -- replicates core logic to ensure that $base_url is set properly. Seems to work. Porting up to 7.x.3 for testing.

Patch for 7.x.3, and tests still pass.

@agentrickard
I can confirm the behavior for my pages. user1 and some other rolls like editors have this problem all the time. mainly we work with Firefox 4, and it happens to me all the time with Firefox 4 too. I can login and see the admin menu but as i visit some other page it seems the i am not login anymore. when i clear the complete drupal cache all went fine and i am logged in on all pages. but when someone visit a page anonymously it happens again to me on this page.

Odd. I would swear it worked.

OK, another patch. Essentially, we have two choices:

-- Duplicate most of the logic from drupal_initialize_settings().

-- Use a cache handler insert instead.

I don't like either option, but the first requires less work by the site, and doesn't require docs changes.

Patch for 7.x.3.

Note that if you manually set $cookie_domain in settings.php, that line MUST go above the include.

And a 7.x.3 version with a test!

FFS.

Then you need to do some work and tell me what's going on. I have WORKING TESTS in the 7.x.3 branch.

Works fine for me on all browsers. Logged in users stay logged in. Anon users are served cached pages.

What does your settings.php look like?

What URLs are you hitting?

What $cookie_domain (if any) are you setting?

Are you setting $base_url manually? (Don't)

And an even better test patch for 7.x.3, which passes.

LiveHTTP Headers (FireFox) output for test user. Works as designed.

If you say it doesn't, I need lots of detail. (See #27)

That's really odd and exactly the reverse of what my test shows.

The patch applied cleanly?

Are you doing anything special with www.* handling at the Domain configuration or Apache / mod_rewrite / .htaccess level?

OK, the only difference is that I have these lines above the include in settings.php. If I remove them, logins break:

// Set cookie domain.
if (substr_count($_SERVER['HTTP_HOST'], 'myexample') < 1) {
  $cookie_domain = '.example.com';
}

So we need to check $cookie_domain handling.

Looks like a session name mismatch caused by the logic loop. This patch should work whether $cookie_domain is set manually or not.

See the notes at line 360:

  // We have set $cookie_domain, so we must match $session_name to it, since
  // that's what will happen inside drupal_settings_initialize() after we run.
  // Essentially, we short-circuit the IF routine when this copied code runs
  // after our routine.
  $session_name = $cookie_domain;

Porting up to 7.x.3 for testing.

Ooops. left in a stray debug statement.

The problem was that you aren't setting $cookie_domain to allow shared login -- I always do that first, and I suspect most people do. That explains why this issue wasn't discovered earlier.

Note that this issue does not affect Drupal 6.

And we made the cache tests work, too.

Committed. Thanks, @torrance123!

when will this get in some stable state, or is there a release coming in version 2.x?

subscribing to the question above

It's ready for inclusion in 7.x.2 and 7.x.3, pending some reviews of outstanding issues.

http://drupal.org/project/issues/domain?text=&status=8&priorities=All&ca...

We are having the same issue with 7.x-2.13 (stable) and tried applying the patch but it failed to patch. We tried to update our site to 7.x-3.x-dev but it completely broke the site and failed to upgrade the database. We've managed to restore the site and reverted to 7.x-2.13

Any chance of this patch being ported to 7.x-2.13, I would be forever in your debt?

At the moment we either have to disable caching on the sites which slows the sites down big time and has been causing us server loads problems or the editors can't edit the site properly as the edit options are gone due to cached pages being loaded.

EDIT: Just realised that there was a 7.x-2.x patch in the above comments. My bad. Sorry.

Hi, i hope somebody still reads this, certainly because i'm probably not in the right place:

I have the exact same behaviour as mentioned in this ticket, although I'm not using the domain access module.
We have configured caching with Varnish, but this results also in browser caching.

The browser cache shows pages from before the login when they are revisited after the login.

Has someone an idea where i need to start looking?

I am using 7.x3.10 version and i still have this problem.
My settings.php contains the line
$cookie_domain = '.mysite.in';
I think I am missing something.This patch is already added in this version.I am using drupal 7.22 version.I am using Boost to cache anonymous user page
Please help

Well, that sounds like a Boost problem, frankly.

You may also be having a cross-domain login issue. See https://drupal.org/node/1197684 for background.

Yes ,That is a boost problem.I disabled boost for now.. Will post this issue in boost module