Situation:
.secure.example.com. I'm not sure if this is xcart related, but setcookie is actually called using secure.example.com. I'm not sure why the "." is appended.Problems:
When I try to use setcookie in https to use the domain .example.com or just example.com, no cookie is created, whether I'm running the store under http or https. The testing code I'm using is:
setcookie('three', 'two', 0, "/", ".example.com");
If I set the cookie to secure.example.com or .secure.example.com it does show up.
Is there a reason the cookie isn't showing up?
The problem was that I was using localhost with a one word domain, 'mydomain', a fact which for some reason was edited out of the original message. At least firefox requires at least two words for an explicitly set cookie, something like mydomain.local. I changed the hosts file to have the domains: www.mydomain.local and secure.mydomain.local, and I was able to set the cookies to .mydomain.local.
Also I found that php automatically puts a "." in front of explicitly set cookies.
Did you try setcookie('three', 'two', 0, "/", ".mydomain.com"); ?
Yes - but the policy is determined by the browser (and on some browsers can be configured).
IIRC the semantics of the preceding . are explained in the cooke RFCs (2109 for the standard cookies states:
A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a FQDN string. (So, x.y.com domain-matches .y.com but not y.com.)
Which I would interpret as meaning that a domian in a setcookie directive intended to be used as a wildcard match should be preceded by a '.' i.e. .example.com - however the spec goes on to say:
Domain=domain Optional. The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot.
Which to me implies the opposite.
I suggest you read it yourself and experiment.
The obvious practical solution is, in the absence of a suitable cookie, to redirect back to the cookie-setting webserver for it to check its cookie then send back another redirect to the originating server with cookie details in the query string, then drop a copy of the cookie associated with the current server.
Alternatively you may get some mileage out of using FQDNs with more sections, e.g.
secure.www.example.com
and
www.example.com
(dropping the cookie for [.]www.example.com)
HTH
C.