I looked in many questions about cookies but I didn't find an answer on my problem. I have following scenario:
A user creates a login on example.com and should get a cookie but only for the subdomain fuu.example.com. I generate following HTTP header part:
Set-Cookie: name=TestUser; Domain=fuu.example.com; Path=/; secure; HttpOnly
But when I make a request to https://fuu.example.com, the cookie will be not added to the request. I wonder if it is possible that example.com sets a cookie for fuu.example.com
. I know that it is possible that example.com set a cookie for .example.com
also for all subdomains for example.com but that's not what I want.
How do I set a cookie for a subdomain? I am not seeing the cookie in a request to the subdomain.
The 2 domains
example.com
andfoo.example.com
can only share cookies if the domain is explicitly named in the Set-Cookie header. Otherwise, the scope of the cookie is restricted to the request host.For instance, if you sent the following header from
foo.example.com
:Then the cookie won't be sent for requests to
example.com
. However if you use the following, it will be usable on both domains:In RFC 2109, a domain without a leading dot meant that it could not be used on subdomains, and only a leading dot (
.example.com
) would allow it to be used across subdomains.However, modern browsers respect the newer specification RFC 6265, and will ignore any leading dot, meaning you can use the cookie on subdomains as well as the top-level domain.
In summary, if you set a cookie like the second example above from
example.com
, it would be accessible byfoo.example.com
, and vice versa.For more details : https://stackoverflow.com/a/23086139/5466401
No.
Besides that(see update below) the cookie would get rejected:fuu.example.com
is an invalid Domain value (it must start with a.
, i.e..fuu.example.com
)The request-host is
example.com
and the Domain attribute value isfoo.example.com
. But the request-hostexample.com
does not has the form HD where D would befoo.example.com
. Thus the cookie gets rejected.Update The current specification RFC 6265, that obsoleted RFC 2109 that is quoted above, does ignore the leading dot. But the effective domain is handled the same: