×
×

How to detect which module creates a session cookie

A lot of Drupal sites have front-end Varnish proxy to make the pages load faster. In most cases, Varnish caches content for anonymous users and sends the request to the webserver for authenticated users. Varnish detects whether a user is anonymous or authenticated based on the absence or presence of a session cookie.

If a session cookie is present, then Varnish assumes that the user is authenticated. If a session cookie is not present, then Varnish assumes that the user is anonymous. The trouble starts when a contributed module adds something in the $_SESSION variable, effectively setting the session cookie, even for anonymous users. Now Varnish will start sending requests to the back-end webserver even for anonymous users. This will increase the page load times and then load on the back-end.

Unfortunately, if this $_SESSION variable is not being set by one of your custom modules, it's not straight-forward how to figure out the contributed module which is setting the $_SESSION variable for anonymous users (note that Drupal core does not use $_SESSION variable for anonymous  users). This is because although you can find the session cookie in Mozilla Firebug or Chrome DevTools, you can find the module name there.

One way is to look for "$_SESSION" string in all the contributed modules. In a smaller site, it may work. You may get the module name which is setting it and you will need to decide whether to keep that module or remove it. But in larger sites, when you have a lot of contributed modules with multiple of them using $_SESSION variable, it becomes more difficult to find which module is using $_SESSION for anonymous users as well.

In this article, we'll show you a simpler way to figure out which is the offending module that is using $_SESSION and in turn setting a session cookie even for anonymous users. Here are the steps:

1) Open Mozilla Firebug and click on Cookies tab. You will see a list of cookies. You can easily find out which modules are setting aucp13n, has_js and session_api_session cookies by just doing string match in the code. But figuring out which module is setting the session cookie is more difficult.

Figuring out session cookies

2) Note down the value of the session cookie In this case, it is "LusM4AB3eKJy7qN4DWhNpuQPplBB4q0teYYZ3r2NBgY".

3) Open the Drupal DB and execute the following query against the "sessions" table.

mysql> select * from sessions where sid = 'LusM4AB3eKJy7qN4DWhNpuQPplBB4q0teYYZ3r2NBgY';
+-----+---------------------------------------------+------+----------+------------+-------+-----------------------------+
| uid | sid                                         | ssid | hostname | timestamp  | cache | session                     |
+-----+---------------------------------------------+------+----------+------------+-------+-----------------------------+
|   0 | LusM4AB3eKJy7qN4DWhNpuQPplBB4q0teYYZ3r2NBgY |      | ::1      | 1411134619 |     0 | session_api_session|s:0:""; |
+-----+---------------------------------------------+------+----------+------------+-------+-----------------------------+
1 row in set (0.00 sec)

Look at the session column. Here you will find all the $_SESSION variables that are being included inside the current session. In most cases, you will know the module name just by looking at the $_SESSION variable name. As an example, in our case it is the Session API module. But it you still can't guess it, then just try to find the $_SESSION variable string in the directory where you have contributed modules and you'll see which file and module is adding this session variable.

Let us know by leaving comments how you liked this nifty trick or if you have a better way to accomplish the same thing!

Services: 
Drupal Performance Tuning

Sign up for our weekly newsletter


Comments

  • by Fab (not verified)
  • Mon, 09/28/2015 - 06:22

Thanks, i found your post cause of varnish not working correct cause my drupal-system is sending a session from some module - even for anonymous-users. And that prevents Varnish from caching.

But - my sessions-table shows a "BLOB" in the session-column. And inside that BLOB is a encoded string, where i cant read any module-information.

Have you got a hint how to read that BLOB or how to decode it?
Thanks in advance.

neerav.mehta's picture
  • by neerav.mehta
  • Mon, 09/28/2015 - 23:13

Are you viewing the DB via phpmyadmin? I have noticed that phpmyadmin shows blob while if you use command-line mysql, you will actually see the text. Let me know if this helped.

  • by Thomas (not verified)
  • Tue, 09/29/2015 - 01:43

I had the same problem and found the module causing this by the steps above.
I used PHP My Admin and clicked on the blob in the table view. It downloaded a file. When I opened this download with notepad, f.ex. , I could see the module information.

  • by Nathan (not verified)
  • Fri, 05/20/2016 - 11:54

Thanks for this mini-tut! To have the session column value output in a readable format use the following SQL (substituting your sid, of course):

select CONVERT(session USING utf8) from sessions where sid = '_______________';

Add new comment