arcgis.com cookies with missing SameSite attribute create thousands of issues in Chrome/Edge Developer tools

3616
8
06-08-2021 04:41 PM
ljlopez
New Contributor III

When you sign into ArcGIS Online, some cookies are stored in the browser for the domain .arcgis.com/. Then, when you browse a web page served in a different domain and referencing the ArcGIS API for JavaScript via CDN, those cookies act as third-party cookies and could potentially be added to the hundreds of requests made to get the JavaScript files of the ArcGIS JS API.

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?

I'm using the ArcGIS API for JavaScript 4.19. Any code referencing the API will reproduce this issue, but you can find an example below.

<html>

<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="initial-scale=1,maximum-scale=1,user-scalable=no" />
  <title>Sketch widget | Sample | ArcGIS API for JavaScript 4.19</title>

  <link rel="stylesheet" href="https://js.arcgis.com/4.19/esri/themes/light/main.css" />
  <script src="https://js.arcgis.com/4.19/"></script>

  <style>
    html,
    body,
    #viewDiv {
      padding: 0;
      margin: 0;
      height: 100%;
      width: 100%;
    }
  </style>
  <script>
    require([
      "esri/Map",
      "esri/views/MapView",
      "esri/layers/GraphicsLayer",
      "esri/layers/MapImageLayer",
      "esri/widgets/Sketch/SketchViewModel"
    ], (Map, MapView, GraphicsLayer, MapImageLayer, SketchViewModel) => {

      const mapImageLayer = new MapImageLayer({
        url: "http://sampleserver6.arcgisonline.com/arcgis/rest/services/VerticalLines/MapServer"
      }); 
    
      const graphicsLayer = new GraphicsLayer();

      const map = new Map({
        layers: [mapImageLayer, graphicsLayer]
      });

      const view = new MapView({
        container: "viewDiv",
        map: map,
        scale: 75000
      });

      view.when(() => {
        const sketch = new SketchViewModel({
          layer: graphicsLayer,
          view: view,
          defaultCreateOptions: { hasZ: false }
        });
        
        sketch.create("point");
        sketch.on("create", evt => {
          if (evt.state === "complete") {
            console.log(evt);
          }
        });
      });
    });
  </script>
</head>

<body>
  <div id="viewDiv"></div>
</body>
</html>

 

8 Replies
TommyBramble
New Contributor III

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?

 

Andy_Morgan
New Contributor III

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.

Bernd_Loigge
New Contributor III

This is an major issue! ESRI should react asap!

Bernd_Loigge
New Contributor III

We ended up hosting everything on our own server.

0 Kudos
ChristopheSuter
New Contributor III

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 ...

Andy_Morgan
New Contributor III

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")

ljlopez
New Contributor III

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.

JérômeDuckers
New Contributor III

Hello,

 

Do you know if Esri provided an update of this problem ?

 

Thanks,

Jérôme.

0 Kudos