We have the drupal secure pages module configured to secure /user and /user/register (actually these two pages are aliased to /sign-in and /register).

So you start out the site on http://ourdomain when you click sign in you go to https://ourdomain/sign-in then after sign in you go back to the main page in http. We have $conf[https] = TRUE; in settings.php to enable mixed mode.

The issue is that after users login and are authenticated they're served up a boost cached page (verified from http headers and html source) which appears as though the user is NOT logged in.

Doing two hard refreshes seems to bypass boost and force apache to dynamically re-render the page and the user see's that they are logged in but obviously that's not an acceptable solution.

So I'm trying to understand how I can force boost NOT to render from cache after login.

This works fine if we continue in HTTPS after login because in .htaccess there is rewrite condition which says if RewriteCond %{HTTPS} on - skip boost.

Likewise if we disable securepages and just use http for login it also works fine.

Its switching from https to http that triggers the boost cache to be used. We only want the login portion of the site to be encrypted.

How can I force boost cached content not to be served after login?

Comments

Anonymous’s picture

Anonymous (not verified) commented
Priority: Major » Normal

This is probably not a boost problem, it is more how the browser works. From your description it appears that after https sign in a cookie is set. This cookie appears to be only valid for the https side of the site. Most browsers will not carry a cookie set in https to http. Is the user still logged in on http, after having signed in using https ?

You need to identify the cookie using firebug or similar in chrome or firefox and then add a matching rewrite rule.

philsward’s picture

philsward commented

Yeah, I'm experiencing the same problem. It "was" only limited to the home page, but now I'm starting to see it on other http pages as well.

Login, go to a http page and it's served the boost page (acts like the user is logged out) Go back to the "login" link and they are signed back in. The login link IS a https page which probably has something to do with it showing as being logged in... regardless, if a user is logged in, shouldn't it be bypassing boost altogether?

@Philip_Clarke You mentioned a rewrite rule, any suggestions on this? I'm pretty clueless with those...

philsward’s picture

philsward commented

Well, looking into it just a bit further, When I login successfully, the cookie is not switching over to authenticated. It's still showing as being anonymous. I have to force reload the page (ctrl+shift+r on chrome) to pull the files from the server before it will change the cookie over. So, it may not be an actual boost issue. I say that, and tested by disabling boost. When visiting an "http" page that is normally cached by boost, there's no problem because the client is loading all of the files from Drupal (instead of the cached boost page) which means it sort of IS a boost issue...

I have a feeling it runs a bit deeper, but I wouldn't know where to begin looking :-/

What needs to happen is that the cookie needs to be re-loaded once a user logs in. Going to look in a different direction for some answers. (Wish me luck!)

philsward’s picture

philsward commented

I created a "nasty" workaround...

Long story short, I created a page and inserted a "meta refresh" into it to refresh the page and redirect to the /user page. Next, I installed Login Destination and have all logged in users being redirect to the "refresh" page. This allows the cookie to refresh over to being authenticated.

Still having a problem with the home page but it might be a secure pages issue...

@Philip_Clarke any thoughts on this?

Anonymous’s picture

Anonymous (not verified) commented

What appears to be happening is one of either two things.

  1. The browser knows it has visited the page and so is loading from the cache (turn on firebug in firefox and disable the cache) sounds like a hard refresh.
  2. The cookie is set during https and so is not valid for an http session, which technically is correct and shouldn't really be affected by a hard refresh.
philsward’s picture

philsward commented

Regarding the second point:

The cookie is set during https and so is not valid for an http session, which technically is correct and shouldn't really be affected by a hard refresh.

Regardless of whether or not the cookie is generated from an https login, shouldn't the _utmv show the user as being logged in? For me, it stays anonymous until the page is reloaded or browsing to another (non-boost cached) page (regardless of http or https). Once I reload the page or visit a non-boost cached page, the _utmv changes over to "authenticated" and from there I'm golden.

I posted out on a securepages issue, detailing the result with similar symptoms to this one: https://drupal.org/node/1400880

Not sure where exactly the problem lies, but I believe it's stemming from the cookie not getting refreshed after a user logs in...

Anonymous’s picture

Anonymous (not verified) commented

The not getting refreshed does sound like browser behaviour, I'd check the headers being sent and possibly modify them for html file to not cache them (your server load would be minimally increased but then it's still not going to hit the db).

The thing is that the browser specification for security is that https cookie should hot be directly transferable to an http domain without a warning to prevent session hijacking. The scenario would be that on an https page, you'd have a cookie set and then "normally" you get warned if an insecure image if on the page, or that you are leaving https, as a clever hacker only need to insert a script to steal the cookie and log in as you (assuming a whole load of things like ip address/ browser checking are not active).

grendzy’s picture

grendzy commented
Status: Active » Closed (duplicate)

Boost is not currently compatible with any kind of mixed HTTP / HTTPS traffic, until #1070048: New folder structure is implemented. This is because the URI scheme (protocol) isn't part of Boost's cache key, so it's not capable of caching a different response for HTTP vs HTTPS.