Duplicate cookies from a domain with a point prefix to a domain without a point prefix

Question

I create cookies from JavaScript on the site, for example. https://example.com since I do not work on the server side. The site has subdomains, for example. mobile.example.com , which should also read / write these cookies. Therefore, I generate cookies with the domain specified as example.com , so that the cookie can be accessed from all subdomains.

 var value="some value"; document.cookie="myCookie="+escape(value)+"; path=/; domain=example.com"; 

This code is executed at page load time in the script tag. When the page is first loaded, in the (Chrome) dev-tools tab "Application", I see that the cookie is set to .example.com with a leading point, which is great. But then I refresh the page and my code runs again and the new value is transferred to the cookie. Now in dev-tools I see a “duplicate” entry for myCookie with the same values ​​- one on .example.com and the other on example.com (without a leading point).

I am refreshing the page again, but the myCookie value in .example.com updated, and one on example.com is not. When I try to read the cookie, apparently myCookie cookie value is on example.com , and I get that value, not the last value (reflected in the cookie .example.com ).

I tried explicitly setting the cookie to .example.com ( domain=.example.com ), but the behavior described above is still happening. Therefore, whenever I set a cookie, it sets the value of .example.com whenever I try to read it, I get it from example.com .

My question is:

• Does anyone have any possible reasons why this might happen?
• Or, if it is not, alternatively offer some workaround for explicit reading from .example.com ?

I can’t provide a link to the site, but I can try to answer any questions that someone might clarify.

Answer 1

Updated Answer

If your goal is to share cookies between all subdomains, allowing everyone to access and set cookies, then you need to specify the root domain whenever you set a cookie.

Suppose you have sub.example.com , sub2.example.com and example.com , and you want to share a cookie between them, and then set the domain to example.com . When you do not specify a domain, a cookie is only a property of example.com or sub.example.com , but if you specify a domain that will be example.com , then it will become available for example.com and all its subdomains will read and write.

domain = domain (e.g. 'example.com' or 'subdomain.example.com').
If not specified, the default value for the host portion of the current document is location (but not including subdomains). Contrary to the specifications, leading points in domain names are ignored, but browsers may reject the setting of a cookie containing such a point. If the domain specified subdomains are always included.
[source: developer.mozilla.org ]

In example.com:

 var value="some value"; document.cookie="myCookie="+escape(value)+"; path=/; domain=example.com"; 

At sub.example.com: (as above)

 var value="some value"; document.cookie="myCookie="+escape(value)+"; path=/; domain=example.com"; 

In both cases, you must install it on example.com . Otherwise, the following situations may occur:

• In example.com , if you forget to set example.com in one place, a new cookie will be created only for example.com , which will be different from the general one and will not synchronize with it, creating a lot of confusion.
• In sub.example.com , if you forget to set example.com in one place, a new cookie will be created only for sub.example.com , which will be different from the general one and will not synchronize with it, creating a lot of confusion.
• You should not set cookies on .example.com as this is not priced according to the above quote.

Possible reasons for the duplication of cookies:

• When the page loads for the first time, JavaScript sets a cookie indicating domain=example.com , which sets a cookie for .example.com , when the second request is made by the browser, sends a cookie to the server, and some code on the server side receives a new cookie sets it on example.com . This can only be verified by checking the response headers of the second request.
• The first time the page loads, JavaScript sets a cookie with domain=example.com , which sets a cookie for .example.com . When a page loads in seconds, any JavaScript code mistakenly sets it without specifying domain=example.com , which sets a cookie for example.com . This can only be verified by checking the JavaScript codes associated with setting cookies.

I believe that accidentally creating domain / subdomain cookies is the cause of all the anomalies you described. Examining each section of the code in which cookies are set can solve the problem.

UPDATE: What is really going on here.

You are using InvocaJS v3.6.6 and AngularJS v1.2.19 , both of which have cookie management features. InvocaJS stores the data in a cookie as invoca_session and sets the domain example.com , so a cookie is set for .example.com . No problem, when AngularJS first sees a cookie, it remembers it. AngularJS stores a copy of all cookies, and when you update a cookie from AngularJS, you actually modify the copy. After that, AngularJS looks at all the cookies, compares them with the copy to determine and update the cookies that AngularJS has updated.

InvocaJS repeatedly changes the value of invoca_session . When AngularJS loops, although all cookies and invoca_session do not match the value that AngularJS has, it considers the value has been changed to AngularJS (as described above) and it updates the invoca_session value, replacing the new value with the old one, (I tested it , this is how AngularJS v1.2.19 worked)

The problem is that Angular v1.2.19 does not indicate any domain when setting cookies (previously predicted as probability of error No. 2). This creates a new cookie with the domain set to example.com . Then, when InvocaJS tries to read the cookie, it reads the old cookie set for example.com .

Changing a cookie with AngularJS

Note 1: You do not understand this, the answer does not always mean that the one who answered did not understand your question. If you collaborated a bit, you could get this answer 7 days ago.

Note 2: Your black box script does not really prove or disprove any of the possibilities I talked about.

Note 3: If you are collaborating now, I can help you further if you do not want to opt out or upgrade AngularJS.

Answer 2

According to the w3schools.com documention , you can use the function to create, receive and verify your cookie.

You can take a look at How cookie browser domains work , as well as here and here , to better understand how browser and javascript handle cookie settings.

---

As you said in your question that the error is visible and Firefox, it may be useful to note that:

Unlike earlier specifications, leading points in domain names are ignored, but browsers may refuse to set a cookie containing such a point. If a domain is specified, subdomains are always on.

---

As you said:

Meanwhile, cookie example.com takes precedence and is the only document.cookie when we analyze cookie value. So, on loading 3 + pages, we just keep getting the value from page # 2 returned from this example.com cookie, instead of the updated value in .example.com

You can double-check whether some data is loaded from the xxx.example.com subdomain when you first load and load the page in the future.

Make sure that if some data is cached during a future reboot.

Finally, you can double check the following headers in your queries:

 Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 

which prevent caching problem.