If you have a View with an exposed filter and reset button Drupal creates a session and returns the cookie for anonymous visitors as part of the the http/303 response from using the reset button. The session is only created once per uncached response.
This issue was identified in an unauthenticated (anonymous) Webinspect scan which included a finding about a cookie not meeting security criteria. This was unusual because I thought Drupal didn't create sessions / provide cookies for anonymous. When I dug into it I realized Views reset was creating the session.
Drupal should not create a session for the anonymous visitor.
Drupal created a session for the anonymous visitor.
You can reproduce this bug by:
1. Installing Drupal core Standard profile.
2. As admin, editing the Frontpage view to add an exposed keyword search field (using search, title field, body, etc. -- it doesn't even have to work), set the "Advanced" > "Exposed form style" settings to "Include reset button" and save the View.
3. As admin, add content of type article, noting words used in the title or body for searching later.
4. As anonymous in an incognito window, other browser (or with curl) and with the browser inspector network tab open visit the site's /node page/path. Click the Application tab in the browser inspector and notice you should not have any cookie from the site.
5. Fill in the search keywords field with a keyword used in the content added earlier and click Apply. Notice you still don't have any cookies.
6. With the browser inspector still open, click/tap the Reset button on the views exposed filter. Notice in the network tab you should have a 303 redirect response which sets the session cookie and sends your browser to the /node page/path. Check the browser inspector Application tab and see there is now a cookie from the site with name "SSESS..."
If you try to repeat this again with a different browser / new browser / curl session with the exact same path & parameters, Drupal will not create a new session or send the cookie and the x-drupal-cache will be "HIT" instead of "MISS". To recreate subsequent times, you need to change something in the parameter (like the keywords).
Fix this code as suggested by larowlan:
The code in question is in
\Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase::resetForm$session = $this->view->getRequest()->getSession(); $views_session = $session->get('views', []); if (isset($views_session[$this->view->storage->id()][$display_id])) { unset($views_session[$this->view->storage->id()][$display_id]); } $session->set('views', $views_session);The issue is the unqualified call to set the session
$session->set('views', $views_session);This should be
if (!empty($views_session)) { $session->set('views', $views_session); } else { $session->remove('views'); }
Active
11.0 🔥
Last updated
Added the proposed code and a test assertion. I can see this happen when testing manually, but the test isn't catching it.
The assertion detects the session when I log a user in a test, so that part works, but in the test, the reset is not triggering the bug. Haven't figured out why yet