Drupal generates session cookies for a particular domain, which is based on $cookie_domain. This is a global variable that can be explicitly defined in settings.php, or otherwise populated in conf_init() invoked during first bootstrap phase.

When $cookie_domain is defined in settings, it can be defined for the top level domain and that means the cookie can be shared on a multisite environment with several subdomains.

However, other cookies generated by Drupal do not follow the same pattern.

In Drupal core we can find 3 places where cookies are generated:

1) In drupal.js we have the cookie "has_js", which is used in _batch_start() to identify javascript enabled browsers. But it can probably be used for the same purpose from other contrib/custom modules. This cookie does not specify domain, it blindly specifies / for the path, and it doesn't care about SSL cookies.

2) In comment module, function comment_form_validate() where name, homepage and mail are saved in 3 separate cookies for anonymous users posting comments. Again, the same pattern as 1).

3) In session.inc, the session cookie. Here's the only place where cookies are generated as it should be, IMO. It uses session_get_cookie_params() to get the arguments that it uses for setcookie().

I would propose a new function in Drupal core to encapsulate the pattern used to the cookie session, so that comment module can reuse it, and then contrib and custom modules to follow. I you grep the contributions repository you'll see how many modules are generating cookies that could benefit from such an API.

For example, it could look like this:

/**
 * Send a cookie.
 *
 * @param $name
 *  The name of the cookie.
 * @param $value
 *  The value to store in the cookie.
 * @param $expire
 *   The time the cookie expires. This is a Unix timestamp so is in number of seconds
 *   since the epoch. By default expires when the browser is closed.
 * @param $httponly
 *   When TRUE the cookie will be made accessible only through the HTTP protocol.
 */
function drupal_setcookie($name, $value, $expire = 0, $httponly = FALSE) {
  $params = session_get_cookie_params();
  setcookie($name, $value, $expire, $params['path'], $params['domain'], $params['secure'], $httponly);
}

For setting cookies in javascript, the path, domain and secure options for cookies could be sent using Drupal.settings, and maybe there could be a set of functions to set, get and delete cookies from javascript. If not, the cookie "has_js" could be created the correct cookie settings, and then it could be shared with the same sites the session cookie is shared.

PS: I opened this feature request as per webchick suggestion on another issue in response to a comment I posted about the "has_js" cookie. Now, I've written a bit more than that, but I hope it helps describe the whole picture.

Comments

webchick’s picture

Component: base system » javascript
Issue tags: +jQuery, +JavaScript

subscribe.

Also tagging.

kkaefer’s picture

markus_petrux’s picture

hmm... I believe that issue adds cookie manipulation methods to Drupal javascript, but does not deal with the way cookies are created, in regards to path, domain, secure and httponly. Also the server side method to create cookies is not addressed. Both issues cover different things.

kkaefer’s picture

Yes, but the code could be based on that.

markus_petrux’s picture

If path, domain and secure options where sent from the server in Drupal.settings, then Drupal.cookie could use those options to provide defaults. And that would cover the client-side aspect of this issue, leaving the server-side part of this issue pending to resolve.

I'll post about this in the other issue.

So, while the other issue implements Drupal.cookie and could also populate Drupal.settings with path, domain and secure, this issue could simply deal with drupal_setcookie(). Makes sense?

sun.core’s picture

Version: 7.x-dev » 8.x-dev
nod_’s picture

we have jquery.cookie.js now, is this still an issue?

markus_petrux’s picture

Yes, because cookie settings do not match unless explicitly specified. This issue does not depend on the method used to manipulate cookies client side, but the way that job is done.

nod_’s picture

Component: javascript » base system

Ok i see, well all we need is a patch now, I think you described the issue well enough.

I put that back on base system because the main issue here is the PHP cookies, in JS we already have something to deal with that, the only thing left to do is expose the settings in Drupal.settings. most of the work here would be making the new php function and make core use it.

There is the JS tag. I'll be keeping track of this one anyway.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.