Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I'm assuming this is something to do with pantheon's various caching layers.
Hopefully someone can help me get this working.
PL works fine locally, but i'm having these odd behaviors when testing on a pantheon multidev:
* closing browser (ending session) logs out the user
* logging out does not clear the PL cookie
Notes:
* PL cookie prefix is "SESSpersistentlogin" which is supposed to bypass pantheon's CDN cache, but maybe something's getting in the way.
* All requests are redirected to wildcard HTTPS (via settings.php)
Screenshots show logging in and successfully settings PL cookie, followed by closing browser to end session, re-opening and requesting a restricted page.
Here's a description of the screenshots:
* #1 Login response: https://www.drupal.org/files/issues/2018-10-03/DevTools_-_afpsd-49-afp-d...
* #2 Request for restricted page: https://www.drupal.org/files/issues/2018-10-03/DevTools_-_afpsd-49-afp-d...
* #3 403 response: https://www.drupal.org/files/issues/2018-10-03/DevTools_-_afpsd-49-afp-d...
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | persistent_login-3004167-8-cookie-prefix.patch | 1.6 KB | gapple |
| #5 | persistent_login-extra_S_in_cookie_name-3004167.patch | 692 bytes | aaronbauman |
Comments
Comment #2
gappleFrom the headers, it looks like the response is not being served from the Pantheon cache (
x-cache: MISS, MISS).The Drupal page cache indicates that it is serving the page (
x-drupal-cache: HIT), but from what I can tell that's because the 403 page is cached.Is there a difference in behaviour between accessing a publicly accessible page when first visiting the site, versus visiting a page that requires authentication?
The persistent login cookie should cause the request to bypass all caches in order to be processed, on both types of pages.
Comment #3
aaronbaumanThanks for your help.
I tried again, rebuilding the drupal cache and visiting the page user/1 immediately upon re-starting the browser
this time the response is not served from cache, but still gets 403'ed: https://www.drupal.org/files/issues/2018-10-09/Developer_Tools_-_Sorry__this_page_is_private___Association_of_Fundraising_Professionals_-_https___afpsd-49-afp-d8_pantheonsite_io_user_1.png
I've also logged the superglobal $_COOKIE, and the persistentlogin cookie that's sent with the request is not present: https://www.drupal.org/files/issues/2018-10-09/macbookair_%E2%80%94_-bash_%E2%80%94_146%C3%9748.png
Is there somewhere else i might find it?
Finally, i confirmed that the persistent_login database table contains a record that would match, if the cookie had made it to drupal.
To me, all this evidence points to a platform issue on pantheon, but let me know if you have any other ideas i might investigate.
Comment #4
aaronbaumanLatest from pantheon, they're telling me the extra "S" is killing the cookie.
ie. if the prefix is "SESSpersistentlogin", the generated secure cookie name starts with "SESSpersistentloginS"
I know this came up in another thread, but can't seem to find it.
Comment #5
aaronbaumanYup, that fixed it for me.
Here's a patch, which is essentially a re-roll of #1506686: User not relogged in on unsecured pages when using mixed mode/secure_pages module, but without changing the call to setcookie
Comment #7
aaronbaumanNot sure why testbot can't find the tests.
This will pass as soon as testbot is fixed.
Comment #8
gapplePantheon must handle the extra initial S for the session cookie's prefix, so I'm wondering if Persistent Login should place the extra S at the beginning in order to prevent http / https cookie conflicts in the same was core does.
If this patch doesn't work on Pantheon, I'll commit without the extra S and recommend that Persistent Login not be used on mixed-mode sites.
Comment #10
aaronbaumanJust tested - you're right, #8 seems to work on Pantheon.
Thanks again
Comment #12
gappleThanks for the effort debugging, testing, and getting info from Pantheon support! I'm surprised this issue didn't come up previously with the 7.x version of the module.
I've also added a note to the configuration form about the additional S being prepended.
There will be a new release shortly that includes this fix.
Comment #13
aaronbaumanawesome, thanks for your quick response