Chrome and Chromium browsers (such as Edge) create an issue for every request and cookie with the following message:
Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute
Because a cookie’s SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.
Resolve this issue by updating the attributes of the cookie:
- Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
- Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests.
The creation of thousands of issues blocks the Developer tools for 1-2 minutes, during which time neither messages appear in the console nor it is possible to refresh the page. Is there any solution for this?
Esri folks, any advice on this? It is causing me some major issues as well. My load time methods can't be debugged as the debugger is frozen processing the nearly 2000 issues.
Anyone know of a way to disable the debugger from logging these issues?
Does anyone have a workaround? This has become a very frustrating problem for me, too. I'm having to wait for 6,000 - 8,000 issues to be logged before my internally hosted application finishes loading. It's a fairly simple 4.19 API application. I really wish we could get ESRI's input on this.
Hi, seems this is a conflict between the cookie set by the JS Api (on Esri's CDN) and the ones set by other Esri pages like documentation etc. Clearing the app site data (in chrome dev tools-> Application), closing the other pages and use another browser (like FF) for documentation solved it for me ...
Yes, this is the answer/explanation. Thanks for posting.
I also discovered this and should have mentioned it in an update after my original reply. The API is not so much to blame. It's the API documentation pages where you start to accumulate many cookie issues. ESRI should hopefully make adjustments on their side with the documentation, but for now we'll have to use a different browser to avoid getting a high issue count.
On a related note, we also discovered something with our internal facing web server used for hosting the secure JS API web application. If we use the fully qualified name in the application URL it will not have any cookie issues generated from this server. (i.e. "servername.abc.xyz/myapplication" instead of just "servername/myapplication")
Thank you both for posting. It's true that the JS API is not to blame, but because the CDN is in the same domain as ArcGIS Online and other Esri pages (such as ArcGIS Developer), all the cookies stored by ArcGIS Online, ArcGIS Developer, etc. act as third-party cookies that would potentially be attached to the HTTP requests made to get the JS API from the CDN.
It's also true that if you remove all the cookies for the domain .arcgis.com/ or if you use a different browser, then the issue is gone, but unfortunately you cannot ask the end users to clean their cookies every time they want to use your application, or ask them to use a different browser.
The option to consume the JS API via the CDN is therefore not free of problems. If no solution is provided, then this option cannot be considered on an equal footing with the rest of options.