Add period prefix to cookie domain?

Can some please explain to me what the difference is between setting this option in Admin - Configuration - Sessions to True or False:

Add period prefix to cookie domain

The default value is true but I am wonder what the danger is in setting it to False. We are on a dedicated server and only host our https://www.clevershoppers.com on the server and I am wondering if I can safely change this setting to False.

Thanks!

Why are you wanting to change it?

DrByte:

Why are you wanting to change it?

To be honest it looks sort of crazy starring at .https://www.clevershoppers.com and when I look at some of the other ecommerce's cookie all of them did not have the . (period) in the cookie set on my computer.

I am assuming it's there for people using subdomain but the perhaps that's not it. I am just not sure if it's needed for our situation. It would be nice to know what some of these functionality are there for.

Another reason that prompted me in looking into is when some of our customers starting having cookie issue.

It's there to deal with cases where the prefix is needed. There are numerous possible reasons for one way or the other, dictated by both the server platform you're running on as well as the browser used by the majority of your customers.

And the fact that MS doesn't follow the rules doesn't help either.

DrByte:

It's there to deal with cases where the prefix is needed. There are numerous possible reasons for one way or the other, dictated by both the server platform you're running on as well as the browser used by the majority of your customers.

And the fact that MS doesn't follow the rules doesn't help either.

So in our particular case (not necessarily what works for most people) is there any danger in setting it to False so it doesn't add the period. Again my thinking might be faulty...but I am thinking https://www.clevershoppers.com is going to create less issue than .https://www.clevershoppers.com

Again, I really didn't even know this existed until a few customers emailed about session/cookie issue. I search the forum and one of the post suggested setting this to false solved similar issues.

To be honest, I am clueless what this setting/function actually does so I not writing as someone that is knowledgeable about this just looking for clarification/direction.

Thanks!

If you set it incorrectly, nobody will be able to shop. Generally you'll know right away (after clearing your browser cache and cookies and restarting the browser) by doing a test yourself.

The setting was added very recently, specifically to deal with occasional cases where session problems existed.

I've asked wilt to respond in more detail for you ...

DrByte:

If you set it incorrectly, nobody will be able to shop. Generally you'll know right away (after clearing your browser cache and cookies and restarting the browser) by doing a test yourself.

The setting was added very recently, specifically to deal with occasional cases where session problems existed.

I've asked wilt to respond in more detail for you ...

Thanks Dr. Byte for the prompt response. It works whether the setting is False or True and I tried in IE, FF, Chrome and Safari. Obviously, there's a reason why the default value is set to True so I will wait for more clarification from Wilt to see if there's an argument one way or the other with the setting.

Thanks agian for your help.

Hi,

If you really want to delve into the history and technicalities of cookies then pls
see

http://www.ietf.org/rfc/rfc2965.txt

http://www.ietf.org/rfc/rfc2109.txt

There are a couple of reasons why the setting was added.

If a cookie is set with out a leading period the cookie is only valid for that domain, and not for any subdomains.

So if my cookie domain is zen-cart.com then the cookie is not valid for https://www.zen-cart.com. This is obviously important given that a lot of sites these days eschew the use of the www prefix.

It's also complicated by the fact that different browsers report the host differently, eg some will add the leading . others won't (although this was mainly Microsoft browsers, and they are a lot better these days) and by the way different servers (apache vs IIS) report the domain to the browser.

and even further complicated by how shared SSL hosts might report the domain. eg where the ssl domain is something like https://somedomain.sharedssl.com

wilt:

Hi,

If you really want to delve into the history and technicalities of cookies then pls
see

http://www.ietf.org/rfc/rfc2965.txt

http://www.ietf.org/rfc/rfc2109.txt

There are a couple of reasons why the setting was added.

If a cookie is set with out a leading period the cookie is only valid for that domain, and not for any subdomains.

So if my cookie domain is zen-cart.com then the cookie is not valid for https://www.zen-cart.com. This is obviously important given that a lot of sites these days eschew the use of the www prefix.

It's also complicated by the fact that different browsers report the host differently, eg some will add the leading . others won't (although this was mainly Microsoft browsers, and they are a lot better these days) and by the way different servers (apache vs IIS) report the domain to the browser.

and even further complicated by how shared SSL hosts might report the domain. eg where the ssl domain is something like https://somedomain.sharedssl.com

Thanks Wilt for the clarification and the links to read more (my head hurts now) :)

I know each situation is unique, in our site's case we use https://www.clevershoppers.com and actually have a redirect that makes sure anything that doesn't point to https://www.clevershoppers.com gets redirected to the www version. So if someone types clevershoppers.com it goes to the www version. It seems odd then in that situation to have the cookie with a period in front of the www.

Again, the logic makes sense from what you've described. I have dropped the leading period from ours and so far so good, it's not affecting site accessibility. At least not that I am aware of so hopefully, I didn't break anything by setting it to false.

Thanks!