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
Comment #1
webchicksubscribe.
Also tagging.
Comment #2
kkaefer commentedduplicate of http://drupal.org/node/305221
Comment #3
markus_petrux commentedhmm... 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.
Comment #4
kkaefer commentedYes, but the code could be based on that.
Comment #5
markus_petrux commentedIf 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?
Comment #6
sun.core commentedComment #7
nod_we have jquery.cookie.js now, is this still an issue?
Comment #8
markus_petrux commentedYes, 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.
Comment #9
nod_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.
Comment #16
ckidowIs there a plan to achieve this in the "near" future?
Comment #19
nod_