I'm working on a site hosted on Acquia and we're using Varnish and Akamai. We don't want anonymous sessions from being saved in the db, as it breaks the caching. I've made a few tweaks, and I'm trying to track down where the sessions are coming from. We're using simplesamlphp_auth for admin logins using Okta and LoginRadius module from /user/login, so it's not a default Drupal 8 installation in regards to login and sessions.

I'm trying to track down where the anonymous sessions are coming from. But I was wondering if there's a way outside of fixing either of these modules to force Drupal 8 to NOT save anonymous sessions to the database. Is there a hook or event that I could use to prevent the anonymous sessions from being saved?

If so, what are the implications? I guess lost cookies that some contrib module may be trying to set?

I'm seeing sessions like this appear:

*************************** 333. row ***************************
      uid: 0
      sid: _oo8QqyuF4tMOIIWr-uCOj8aqsknzV1WWkmf0bHzlmQ
timestamp: 1557934618
  session: messages|a:1:{s:7:"warning";a:1:{i:0;O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:" * string";s:57:"Your session was deliberately ended from another session.";s:12:" * arguments";a:0:{}s:10:" * options";a:0:{}}}}
*************************** 334. row ***************************

or this:

          uid: 0
      sid: _VmVWTDsbgQYOcZFxN15Z5j-s4jt4YmsjSZGggphAIM
timestamp: 1557928795
  session: _symfony_flashes|a:1:{s:5:"error";a:1:{i:0;s:49:"Access denied. You must log in to view this page.";}}_sf2_meta|a:3:{s:1:"u";i:1557928795;s:1:"c";i:1557928795;s:1:"l";s:7:"2000000";}
*************************** 335. row ***************************

I think part of the issue may be that messages aren't getting displayed to the user on cached pages, so the anonymous sessions aren't being emptied of their _symfony_flashes

The most concerning one dumps a ton of user data, I think this from loginradius:

*************************** 332. row ***************************
      uid: 0
      sid: _2PXluVM2rAY29hE-HFkNQQ8_nPdP4QeU4Y3PoX40ws
timestamp: 1557870161
  session: _sf2_attributes|a:5:{s:12:"access_token";s:36:"fb98d952-f1a2-4ba3-820e-2db2c7313008";s:17:"user_profile_data";O:8:"stdClass":146: etc. (I'm not going to post the data here)
  • When you dump the session content in the superglobal and the request, what kind of data is in there? Core shouldn't set much session data other than short living things like messages. If this is from contrib modules you should be able to evaluate the purpose of this data and if you need it.
    – 4uk4
    May 12, 2019 at 19:19
  • 1
    OK, this is a module constantly setting the same error message. A message survives normally only until the next request, but if this module is setting it then again it will never go away.
    – 4uk4
    May 12, 2019 at 19:34
  • Thanks, it looks like the login radius module redirects to /user/ciamlogin/ and in the process it's writing an anonymous session to the database.
    – oknate
    May 12, 2019 at 19:38
  • 1
    No, then it couldn't display the error message on the login page.
    – 4uk4
    May 12, 2019 at 20:03
  • 1
    Yes, the symfony flash bag does this automatically when Drupal gets the message to display it.
    – 4uk4
    May 12, 2019 at 20:32

2 Answers 2


Find out which modules set session data by dumping these variables for anonymous requests:


You can ignore the symfony metadata starting with _symfony or _sf2.

Then search the code base for session set() commands setting this data. You can then either change this code or remove the session data in your own code with remove().

When all session data is removed the session will be destroyed automatically at the end of the request. The metadata doesn't count.

A special case is the symfony flash bag. Data stored here is normally only kept between two requests. Ideally the first one is a redirect so the second one happens immediately. Drupal uses the flash bag for system messages. The messages are displayed and removed by the status messages block, which is enabled by default. The messages block is uncacheable and re-built on each request, because of how the caching system handles requests containing a session.

  • So another thing to look for would be page templates that anonymous users visit that lack the message block?
    – oknate
    May 18, 2019 at 11:05
  • Yes, check that the region is printed which contains the block.
    – 4uk4
    May 18, 2019 at 11:34

In this article from Varnish explain how to remove the anonymous user sessions: https://www.varnish-software.com/wiki/content/tutorials/drupal/drupal_step_by_step.html#cookies

If Varnish works fine, Drupal should not know that there are anonymous users around it.

Your Answer

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

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