Incompatible with Varnish

Exactly how are cookies removed? As far as I understand from the Varnish 3 docs, all they do is send requests to the backbend when a cookie is set in the request header. When a Set-Cookie is set in the response header, the page isn't cached. Perhaps the behavior used to be different, but depending on what exactly happened, this issue may fix it: https://drupal.org/node/1492622

There are a few Varnish configurations around which strip all cookies except for /SESS.*/, etc. One example is https://fourkitchens.atlassian.net/wiki/display/TECH/Configure+Varnish+3... and another is the configuration Pantheon run (http://help.getpantheon.com/pantheon/topics/does_pantheon_remove_cookies).

In the former case, the correct response is certainly "please learn how to configure your Varnish correctly" but it'd be nice to have the cookie name configurable for cases like Pantheon, where Varnish is outside of the Drupal developer's control.

FYI, I hacked the module to use SESSsessionapi to get it to work on Pantheon.

Would a JS method of initiating a session cookie fix it? See: #1492622: Option to initiate Session API with JS

I'm not opposed to adding a configuration option for the cookie name, but prefer the JS solution and that should at least be prioritized.

Hi a.ross,

I don't see how that will help (the JS cookie will still be stripped out of the request by Varnish because it doesn't look like /SESS.*/) but I'll test it tomorrow.

Cheers.

I was under the impression that varnish only strips out cookies from the Set-Cookie header? Does it also strip out cookies (set from a JS file) from the HTTP request?

I don't know about cookie stripping on *responses*, but many configurations will strip "useless" cookies from the request too. Typically this is a good thing (Google Analytics, other sites on the domain/s, etc.) but causes problems when it removes a cookie you need.

In Pantheon's case, Drupal will *only* see cookies that match the pattern /SESS.*/ because Varnish will strip all other cookies from the request before forwarding it to the upstream server. Renaming the Session API cookie to SESSsessionapi gets around this stripping and Flag and my custom code using Session API all work fine on Pantheon now.

Cheers.

What's the current situation here? Has anybody got the Session API module working in a varnished environment? What needs to be done in order for that to work? Thanks.

I don't know whether or not it makes sense to make this prefix configurable. What does need to happen, though, is that old "unprefixed" session should not be broken when upgrading.

I don't really understand the discussions taking place as far as the cookie names and how it's being accessed. I just want to know if and how to use this module in conjunction with Varnish.

Not yet. This feature request is still open

The situation is this: some Varnish configurations (the one used by Pantheon, for example) remove all cookies from the request except those which match a specific pattern (/SESS.*/, for example).

If this causes a problem for you, you will need to change either your Varnish configuration or the name of your cookie. For a platform like Pantheon, you can't change the Varnish configuration so you'll have to change the cookie name.

Thanks thsutton. We're on Acquia's platform so I'll have to dig into that and see if it will work or not. Great feedback!

A fix for using session api module in Pantheon.
Changed the session/cookie name to: SESSsessionapi.

I would prefer this to be configurable by the site builder. I will accept a patch that does that.

#14 works fine in Pantheon. Would be nice to have a field in settings where the user can define the session name or prefix.

For those using the vcl from FourKitchens, or some variation, you can add support for the session_api_session cookie by modifying a single line:

  if (req.http.Cookie) {
    set req.http.Cookie = ";" + req.http.Cookie;
    set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
    set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE|session_api_session)=", "; \1=");
    set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
    set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
  ...
  }

I applied the patch and still anonymous can't see flag links.
Site is on Pantheon, using latest stable release of Flag and Session API (+patch).
Flag is on a commerce product, displayed as link in Full view mode through a View showing rendered entities.

PS: Please at least mention something on the module page.
Just lost a entire day wonder why my f*** flag links wouldn't show up for anonymous users..

Here is patch that replaces string literals for the cookie name,'session_api_session', with a call to the function session_api_get_cookie_name.

The function simply uses a variable

function session_api_get_cookie_name() {
  return variable_get('session_api_cookie_name', 'session_api_session');
}

@a.ross I also added this setting to the module's configuration form.

I stick with the current cookie name, 'session_api_session', instead of switching the default cookie name like in the patch in #14 because developers might have custom code that uses this cookie name for other purposes. Changing the default name would break any custom code.

To get the module to work with the problems people are having in this issue they will have to set the variable to "SESSsessionapi" or something else that works with their setup.

That could be done by:

1. Updating the setting via the configuration form for this module
2. setting the value in settings.php $conf['session_api_cookie_name'] = 'SESSsessionapi';
3. Or using drush: 'drush vset session_api_cookie_name 'SESSsessionapi'

Cool! Patch is looking good.

1. +++ b/session_api.admin.inc
   @@ -20,5 +20,12 @@ function session_api_settings_form() {
   +    '#type' => 'textfield',
   

   Can we use the machine_name type for this? https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.h...

2. +++ b/session_api.admin.inc
   @@ -20,5 +20,12 @@ function session_api_settings_form() {
   +    '#description' => t("This name will be used for the cookie key used by this module. Certain names for cookies might be incompatible with caching systems such as Varnish."),
   

   I'd like to warn the user here of the consequences of changing the setting. The cookie name could collide with other cookies if changed carelessly. Also, simply by changing this variable, all current Session API sessions are invalidated.

Can we use the machine_name type for this?

Won't this stop the admin from using characters that are valid for cookie names but not for machine names?

I don't think the name used in this issue, "SESSsessionapi" would be a valid machine name but it would be valid cookie name.

Also valid cookie names probably vary from browser to browser and according to different Varnish setups.

IMHO I think trying to validate the cookie name would something that lead this issue to never be resolved.

It would probably lead to people opening issue like "Can't set cookie name to ..... "

I'd like to warn the user here of the consequences of changing the setting.

That makes sense.

Let me know what you think about the machine name and I will re-roll patch.

Won't this stop the admin from using characters that are valid for cookie names but not for machine names?

Yeah, you're absolutely right.

I'd like to warn the user here of the consequences of changing the setting. The cookie name could collide with other cookies if changed carelessly. Also, simply by changing this variable, all current Session API sessions are invalidated.

ok this patch just adds the warning to the last patch.

Testbot

Committed. I just made a minor change to the patch and you missed one occurrence of 'session_api_session', I fixed that.

Thanks!

 function session_api_start_session() {
-  $_SESSION['session_api_session'] = '';
+  $_SESSION[session_api_get_cookie_name()] = '';
   drupal_session_start();
 }

Yeah I wasn't sure about this 1. Since it was for $_SESSION and not $_COOKIE. Didn't know if these 2 keys had to be the same or just happen to be.

The content of the $_SESSION variable is (normally) output in the form of a cookie in the response. http://php.net/session_start

I have managed to resolve the issue within the varnish config file:

sub vcl_recv {

set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|context_breakpoints+|session_api_session+|NO_CACHE|)=", "; \1=");

}