2

I am trying to set the cookie for the specific domain(as I have multiple websites and I don't want to share them) so for this, I changed the configuration as OOTB Magento provides this feature (Stores > Configuration > General > Web Default Cookie Settings > Cookie Domain) and I added my domain and set the Cookie Path / and saved the configuration, clear cache, cookies . On the frontend side, I can see all cookie set to the to my domain expect form_key which is adding extra .(dot)

enter image description here

So is this correct way or am I missing something to set the cookie for the specific domain? and another question is

Why Magento adding . (dot) to only form_key cookie?

2

Before worrying about why it happens, you may want to consider whether it's actually a problem for you. It seems to be that having a leading dot shouldn't be affecting cookie behaviour in the browser.

The leading dot means that the cookie is valid for subdomains as well. RFC 6265 Section 4.1.2.3 defines this as so modern browsers should ignore leading dots if you're on the base domain.

For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)


EDIT:

I've done a little bit of testing and it looks as though Magento wasn't actually sending the cookie domain with a leading dot as the Set-Cookie header by default, so this points the issue towards being browser behavious and how it handles the Set-Cookie headers.

Chrome dev tools network inspector:

Chrome dev tools network inspector

Chrome dev tools cookie list: Chrome dev tools cookie list

I suspect that the cookies you seen without the leading dot are from cookies assigned by JS functions, rather than a Set-Cookie header.


EDIT 2:

As you mentioned in the comments below, the JS function PHP function for the cookie JS here does look like it adds the leading dot to the domain when the form_key is instantiated here, though any further communications with that form_key have the leading dot stripped in the headers too.

Cookies for form_key from server

This could be a core bug, or it could be a configuration issue (I'm more inclined to think the former of the two)

  • 1
    Thanks for the answer :) +1 for info. What if I don't want to share cookie for a subdomain? Is there anyway? – Keyur Shah Jul 31 '18 at 6:17
  • @KeyurShah judging from the wording of the RFC I'd say it seems to try explain that any cookie assigned to the primary domain can be shared with a subdomain, by default. – Rhys - SproutDesk Jul 31 '18 at 10:11
  • 1
    Thanks a lot for more info @Rhys, yes, I have multistore with a number of subdomains so to achieve this I changed the cookie domain (from the configuration as I mentioned in the question) and it works expect form_key and PHPSESSID cookie which addes leading dot that's why I am confused. might be you have some idea on this :) – Keyur Shah Jul 31 '18 at 11:41
  • 2
    I think I might have cracked it... I don't think Magento actually is sending the domain with a leading dot for the cookie. I believe it's the browser itself adding this. I turned off JavaScript in my browser and reloaded a blank Magento 2.3 with the cookie domain set up in the admin area and the headers returned with domain=magento23.dev in the Set-Cookie header for the HTML response. I believe the ones without the leading dots are being assigned to the browser by JS functions, so not susceptible to the same browser behaviour as when it comes via a header. snag.gy/JUT5qa.jpg – Rhys - SproutDesk Jul 31 '18 at 18:16
  • 1
    Hi, added a little more finding above. I'd say this could be a core bug that you're finding in your situation so maybe you should open a GitHub issue on this... – Rhys - SproutDesk Aug 1 '18 at 11:16

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.