How do Pressflow Drupal sites handle user Cookies?

Question

Is this something handled by Drupal? What PHP, Apache, Varnish settings affect cookies?

Additionally, what's the difference in cookie handling between plain-vanilla Drupal and Pressflow?

I was seeing that in drupal_session_commit() boostrap.inc calls session_destroy():

session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie. To use the session variables again, session_start() has to be called.

In order to kill the session altogether, like to log the user out, the session ID must also be unset. If a cookie is used to propagate the session ID (default behavior), then the session cookie must be deleted. setcookie() may be used for that.

Apparently in Pressflow drupal_session_commit() gets called on every page like this:

// Perform end-of-request tasks on every page.
drupal_page_footer(), common.inc
    // Write the session, and open one if needed.
    drupal_session_commit(), bootstrap.inc
        // If our user is anonymous, Pressflow "Destroys empty anonymous sessions"
        // Destroy all data registered to a session
        session_destroy(); 
            // Called by PHP session handling with the PHP session ID to end a user's session.
            sess_destroy_sid($sid), session.inc

What implications, if any, does this have for user tracking in software like Omniture and Google Analytics?

See related post to cookies here: https://stackoverflow.com/questions/871283/how-do-tracking-cookies-work

Link to Pressflow documentation.

Answer 1

Cookies/sessions are handled by both Drupal and PHP. Drupal register some functions that PHP will call, when certain things need to happen, like destroying a users session. PHP handles most of the basic stuff and Drupal override some of it, store users sessions in the database.

I'm not familiar with Omniture but if it's anything like GA, a users session/cookie wont effect tracking at all. Cookies are used to identify the user, so they don't have to type in their username/password at every page. Without cookies, Drupal wouldn't be able to tell the users apart and would need some other form of identification, like a login for every new page load.

This is why, some people try to steal cookies, as that is the same as having the user log in and leave the computer, given the thief full access.

Answer 2

1) Is this something handled by Drupal?

Drupal does handles cookies, but it only handles it's own first party cookie. Like @googletorp said, Omniture and Google Analytics use their own cookies.

2) What PHP settings affect cookies?

drupal_session_initialize(), on boostrap.inc calls session_set_save_handler(), which overrides PHP's default session handling funcitons with Drupal's.

On Pressflow, at the end of every page, drupal_page_footer() is called. The code shows that if the user is anonymous, Pressflow deletes the current session id from the database and empties any cookies that might have been set. Refer to sess_destroy_sid() on session.inc.

3) What Varnish settings affect cookies?

Both Google Analytics and Omniture are able to generate visitor statistics without cookies because statistics are generated using hard-coded image requests (web beacons). However, in order to track persistent statistics (how often x user comes to my page), Omniture issues a cookie with an unique user ID - and when that user comes back to my page, he presents me with that cookie and I can say "OK, user x visited me for second time this week, and third time this month, and so on". This is done using persistent cookies, which are an actual file sitting in the user's computer.

The problem with Varnish is that it is generally set to strip cookies from the request because if the request comes with a cookie attached to it, then Varnish doesn't serve a cached page. Because Omniture sets these cookies for every user out there, it means that if you don't strip the Omniture cookie from the request, Varnish is never going to serve a cached page.

So it's either you track persistent statistics, or you find a way to pass that cookie through Varnish, and yet manage to serve the cached page, which is something I haven't heard of yet.

Answer 3

The real answer is that both Google Analytics and Omniture use specific cookies (not the cookies used by Drupal), and perform their tracking completely independently of Drupal sessions.

The new session handler introduced by Drupal 7 (and later backported to Drupal 6) in Pressflow does not interfere with either Google Analytics or Omniture tracking of users.

For the same reasons, cookie-stripping in Varnish do not interfere with the tracking of users.

Answer 4

All components handle user cookies on different levels.

Web browsers sets the cookies and make sure they're passed over to the next requests based on the domains criteria and expiration date (as par of a HTTP header).

Drupal reads cookies via PHP (setcookie/session_destroy) functions and authenticate the users.

Varnish parses incoming requests and decides whether page should be cached or not and it may have the logic to keep, modify or drop all other cookies that Drupal doesn't need to know about. Here is example Varnish logic (in .vcl file config) as result of configuring Drupal with Varnish:

1. Append a semi-colon to the front of the cookie string.
2. Remove all spaces that appear after semi-colons.
3. Match the cookies we want to keep, adding the space we removed previously back. (\1) is first matching group in the regsuball.
4. Remove all other cookies, identifying them by the fact that they have no space after the preceding semi-colon.
5. Remove all spaces and semi-colons from the beginning and end of the cookie string.
6. If there are no remaining cookies, remove the cookie header. If there aren't any cookie headers, Varnish's default behavior will be to cache the page.