I have a Drupal 8.6.10 site which has a very confusing logout bug:

  • I have a page that has various elements on it as images, js, css and so on.
  • I load that page and everything works fine
  • I add an image to that page
  • I load the page again, everything fine, also the image is showing.
  • I delete the source image and the image style derivatives of that image
  • I reload the page -> I get logged out!

I can see on the call to the image (which returns a 404 because the image is not existing), the value of the SSESS Session cookie is changed (so the session ID) thus I'm losing the connection to my session and get logged out.

I have already proven that this happens inside the execution of PHP and has nothing to do with varnish (logging at the very end of index.php, before the answer gets sent, shows already the changed session id using session_id() ).

I have a parallel installation which is still on Drupal 8.3.7, and which contains various fixes of this issue: https://www.drupal.org/node/2743931 When I remove the fixes for the issue, the bug does no more appear.

However after the update to 8.6.10, I removed all the fixes because the issue has been fixed in core, and despite the fixes being removed, the logout bug still appears.

How can the session id even be changed? Calling session_start() a second time does not work and session_regenerate_id (the only one in the symfony core) is never called.

Please help me on this one, as I'm currently at the end of my latin. Thanks!

1 Answer 1


I finally found out what was the exact problem in my case:

  • I had varnish which per default, strips all cookies from the request to images. So when an image style is called, the request won't get any cookies and is thus an anonymous request.

  • The image is not present, so PHP is called to generate it.

  • A custom module invokes code that includes private tempstore (via Event listener but could also be hook_init() or something similar).

  • The SessionStorage is not aware that there was already a session because varnish stripped the cookie away. It therefore just started a new session (with the same cookie name but with another value). That was the return cookie.

At least it's solved now. An alternate way could also be that varnish could also filter all returned cookies, but this has to be configured / coded in the varnish config.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.