Can the 'Domain' of set-cookie valued any domain？
eg:
when login www.google.com,
a xhr to facebook.com is requested
and responsed with a response Header set-cookie:aaa=1;domain=twitter.com.
Will the cookie be set to domain=twitter.com successfully？
No. It cannot. HTTP clients, user-agents and web browsers are required to reject any Set-Cookie header that specifies a Domain= that does not match the Origin of the current document.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
A cookie for a domain that does not include the server that set it should be rejected by the user agent.
The following cookie will be rejected if set by a server hosted on originalcompany.com:
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
A cookie for a sub domain of the serving domain will be rejected.
The following cookie will be rejected if set by a server hosted on example.com:
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
The Set-Cookie header's Domain= parameter is to allow a subdomain's website to allow its cookies to be used by a parent domain website, but not the other way around.
Note that browsers are aware of the structure of ccTLDs, so a website at example.co.uk cannot use Set-Cookie, Domain=co.uk, but a website at subdomain.example.co.uk can use Set-Cookie, Domain=example.co.uk.
Related
I have a requirement where i need to invoke a SOAP Webservice operation for login and get the cookie from the SOAP response and use the cookie to invoke another SOAP operation to retrieve some data. The Login operation response has a cookie(Set-Cookie) which looks like ASP.NET_SessionId=vqjucdxcxrgg5swr0f3z0peb; path=/; HttpOnly; SameSite=Lax
Now how do i map this cookie to the retrieve operation. Do i map ASP.NET_SessionId=vqjucdxcxrgg5swr0f3z0peb; path=/; HttpOnly; SameSite=Lax fully or just ASP.NET_SessionId=vqjucdxcxrgg5swr0f3z0peb or just vqjucdxcxrgg5swr0f3z0peb. I tried all three options and i am getting java.lang.IllegalArgumentException: Port may not be negative error when i invoke the retrieve operation. Please let me know if i am doing anything wrong. I am using Tibco BW to invoke the SOAP operations.
Found the answer to my question in the link https://en.wikipedia.org/wiki/HTTP_cookie .Please read below
Setting a cookie
Cookies are set using the Set-Cookie HTTP header, sent in an HTTP response from the web server. This header instructs the web browser to store the cookie and send it back in future requests to the server (the browser will ignore this header if it does not support cookies or has disabled cookies).
As an example, the browser sends its first request for the homepage of the www.example.org website:
GET /index.html HTTP/1.1
Host: www.example.org
...
The server responds with two Set-Cookie headers:
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...
The server's HTTP response contains the contents of the website's homepage. But it also instructs the browser to set two cookies. The first, "theme", is considered to be a session cookie since it does not have an Expires or Max-Age attribute. Session cookies are intended to be deleted by the browser when the browser closes. The second, "sessionToken", is considered to be a persistent cookie since it contains an Expires attribute, which instructs the browser to delete the cookie at a specific date and time.
Next, the browser sends another request to visit the spec.html page on the website. This request contains a Cookie HTTP header, which contains the two cookies that the server instructed the browser to set:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
…
This way, the server knows that this request is related to the previous one. The server would answer by sending the requested page, possibly including more Set-Cookie headers in the response in order to add new cookies, modify existing cookies, or delete cookies.
The value of a cookie can be modified by the server by including a Set-Cookie header in response to a page request. The browser then replaces the old value with the new value.
Cookie attributes
In addition to a name and value, cookies can also have one or more attributes. Browsers do not include cookie attributes in requests to the server—they only send the cookie's name and value. Cookie attributes are used by browsers to determine when to delete a cookie, block a cookie or whether to send a cookie to the server.
when i post the data using POST method in woocommerce api. i am getting cors issue
Access to fetch at 'http://localhost/wordpress/wc-api/v3/customers?oauth_consumer_key=ck_64d88e1fa3516e9f5a06b6053f02976a534d3f8f&oauth_nonce=zsu3ysEnFHhvrZt4Nc7H66Dgu28H20K7&oauth_signature_method=HMAC-SHA256&oauth_timestamp=1562587817&oauth_version=1.0&oauth_signature=KtFxvyQNklUlfCi6rNWyJ0DEJ6AS2ZbwbO44u%2FEqxG4%3D' from origin 'http://localhost:8100' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
You have to set a Access-Control-Allow-Origin header on each request to the server, if your server is on a different domain than the app on which you are making those requests (the server sets it as a response header). Adding that header tells the system that the external domain "localhost:8100" is allowed to make those requests.
You cannot circumvent this requirement in vanilla browsers, because it is a built in security feature to reduce CORS attacks
PS. different ports on the same domain are considered to be different domains. Thus example.com will get a 401 error, if you are making a request to example.com:8100. Same goes for localhost, or any other domain.
Example code from an Apache2 web server .conf file, that I personally use to set these headers.
SetEnvIf Origin "^http(s)?://(.+\.)?(staging.\xxx\.com|xxx\.com|xxx\.local|xxx\.local:4200|a2\.local)$" origin_is=$0
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is
Just replace the xxx.com domains with localhost:8100 or whatever else you need in that array. (if you are using Apache web server)
As a result, the Chrome network tab should have an Access-Control-Allow-Origin header on attached to the request
If in http response header the "set-cookie" properties "path" and "domain" are set for a site say a.com as path=/, domain=a.com
The role of path and domain states-
path: url path that must exist in request resource
domain: restrict host to which cookies will be sent
not what is the role of setting "SameSite" property? as it's use case states cookie not to be sent along with cross-site requests. as the cookie scope is already restraint to same domain by path and domain attributes.
will SameSite: Lax ovewrites the restriction imposed by path/domain
What is the role of setting "SameSite" property?
There are 2 concept here: the requested resource and where that request is originated. For example, you are visiting a.com, and sends an HTTP request to b.com (through Ajax or image loading or hyperlink etc.) In this scenario, the requested resource is data in b.com, while the request is originated from a.com
domain and path is used to restrict which requested resource the cookie can be applied, while SameSite is used to restrict where that request should be originated.
For example, if domain is c.com, it won't be applied in request sent to b.com, no matter whether that request is sent from b.com website or not. Meanwhile, if SameSite is Strict, as long as you are not in b.com website, the HTTP request to b.com won't bring that cookie, even if that "SameSite-Strict" cookie's domain is b.com and path is /.
Will SameSite: Lax ovewrites the restriction imposed by path/domain?
No. SameSite and domain/path are 2 different thing.
We have a site where we are using cookies for tracking purposes. Now we are thinking in changing the domain of our site but we will want to still recognise User's sessions from the old domain. Is this possible?
You can't retrieve cookies that belong to other domains. As a workaround (in case you can still use the old domain); by creating an iframe inside http://newdomain.com from http://olddomain.com, you can get cookies and send to parent via postMessage.
Cookies are affected by same origin policy but you can bypass it with CORS (Cross-origin resource sharing).
CORS is a play between browser and server.
Basic idea is allow ajax request to cross domains but you can use to share cookies(security measures should be taken).
Browser send a request with Origin header.
If the server allows the request then it reply with Access-Control-Allow-Origin header with the value of origin.
If the server doesn’t reply with the header or don’t match Origin with Access-Control-Allow-Origin browser disallow the request.
But it doesn’t send cookies or something like that by default(you have to add “allow-credentials” extra header).
With CORS you can share the session between domains adding to new domain server the following headers:
Access-Control-Allow-Origin: https://original-domain.com
Access-Control-Allow-Credentials: true
More info about CORS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
http://quickleft.com/blog/cookies-with-my-cors
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.
No. Besides that fuu.example.com is an invalid Domain value (it must start with a ., i.e. .fuu.example.com) (see update below) the cookie would get rejected:
To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true:
The request-host is a Fully-Qualifed Domain Name (not IP address) and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots.
The request-host is example.com and the Domain attribute value is foo.example.com. But the request-host example.com does not has the form HD where D would be foo.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:
[…] 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.)
[…] the user agent will accept a cookie with a
Domain attribute of "example.com" or of "foo.example.com" from
foo.example.com, but the user agent will not accept a cookie with a
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
The 2 domains example.com and foo.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:
Set-Cookie: name=value
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:
Set-Cookie: name=value; domain=example.com
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 by foo.example.com, and vice versa.
For more details : https://stackoverflow.com/a/23086139/5466401
Actually, there is a simple and fully cross-browser support way for sharing cookies between original domain and subdomains but you should share it in setting time, for comfortable working with cookie stuffs in browser I'm using js-cookie and with the below setting cookie it could be shared between original domain and all of its subdomains:
Cookie.set('key', 'value', { domain: '.domain.com' })
// a . added before domain name
Hint: Adding this . will share cookie with all sub-subdomain.