2

Ok, I've got my primary site running EE1 at www.example.com. I've set up a subdomain of static.example.com, from which I want to serve static assets; specifically, files that don't need cookies being attached to the requests.

My EE -> Admin -> SysPrefs -> Cookie Settings are:

Cookie Domain: .www.example.com
Cookie Path:        (ie. blank)
Cookie Prefix:        (also blank)

Once those settings are verified, I logout of the backend and use Firebug + FireCookie to remove all cookies for the current domain. Loading up, say, static.example.com/css/main.css shows that indeed, there are no cookies being transmitted with the static file request.

However, if I then load up the frontend of the EE site at www.example.com, I see a number of cookies being stored: a JW Player cookie and a few Facebook and Google Analytics cookies - all of which are expected, along with 3 EE cookies: exp_tracker, exp_last_visit, and exp_last_activity. All of those EE cookies have domains of .www.example.com - but somehow ALL of them are also being transmitted when I request the aforementioned static.example.com/css/main.css file.

I'm no cookie expert, but I would have expected that by specifying the .www subdomain for the cookies in EE, they would have been restricted to requests that include that subdomain.

What am I doing wrong?

1

Sandwich, I'm no expert here either, but looked over your problem to see if I could learn something. Here's what I could suggest.

  • I think the basis is that cookie domain setting in EE is for the purpose of defining what domain sent cookies will be assigned to - but it isn't about whether to send cookies. Sending cookies is presumed.

  • I thought of working with the cookie consent module, which does allow restricting cookie sending. However, this is a (recent) EE2 addition, so it's not going to help on an EE1 site.

I'm not sure why you want to restrict cookies on resources, but maybe you could segregate those static resources further, and only put on the subdomain things that are truly static. Even a css file as in your example can be so, of course, and you could just copy-paste from a css template if you develop there. Then you wouldn't invoke EE at all on the subdomain -- by not putting an index.php there, and by the way you address the resources in your templates or other html. Then there would be no cookies.

If the question is actually to do with EU cookie restrictions, then I think you'd need to update to latest EE2 to gain best use of the new module. Reference Cookie Consent, and be sure to notice the comment at bottom which says where to get the module at present.

| improve this answer | |
  • My understanding is that a browser will send all cookies that are relevant to a domain (or subdomain) with every HTTP request the browser makes of that domain. So the problem here is that EE seems to be defining cookies that are relevant to all subdomains of example.com, instead of restricting them to just www.example.com. The benefit of this is less network traffic. The static.example.com subdomain has no EE files on it - no index.php, no path.php, nothing. This issue has nothing to do with the EU cookie consent stuff. :) – Sandwich Mar 3 '13 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.