ES Modules (v4.19) throwing CORS errors

2979
10
Jump to solution
05-03-2021 01:31 PM
by Anonymous User
Not applicable

Hello,

I have been using the JavaScript api in an angular app since 4.17, I was able to work with TypeScript and the builds are working fine with WebPack, when 4.18 became available, I decided to ditch our reliance on the WebPack scripts that were being used, and went with the 'supported' method of copying the assets and referencing them via esriConfig.assetsPath, That was working great after some trial and error, and now that 4.19 is out and 'production ready' we wanted to move away from the reliance of having to deploy all the assets with the web app (deployed to containers, so an extra ~20MB per deploy would be good to get rid of).

I removed the line that was setting the assets path, removed the copy of assets locally and updated the reference to the CSS stylesheet. all is _almost_ well; the app loads, requests are made to the assets, paths are correct, BUT I am getting CORS errors from the ESRI servers when trying to load the assets (js.arcgis.com)? I can manually navigate to the links just fine, so I know the paths are correct, but the webmap won't load any esri widgets, all my custom code is working fine, Portal items are loaded and display, but any request to the javascript assets fail with the CORS error (just one example):

Spoiler
Access to fetch at 'https://js.arcgis.com/4.19/@arcgis/core/assets/esri/widgets/LayerList/t9n/LayerList.json' from origin 'https://EXTERNAL-URL.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Fonts and CSS from the CDN work just fine (main.css, icon for basemap widget, font file all get sent down fine).

I can go back to using the local assets, but since that is ~20MB, I would really like to avoid having to depend on it to make the maps work. Thanks for any help!

0 Kudos
1 Solution

Accepted Solutions
AndyGup
Esri Regular Contributor

I have a couple questions on the CORS errors. There's nothing in the ArcGIS JS API that should be triggering preflight:

  • Do you know if your secure login system is creating signed URLs? It could be injecting additional header fields into the ArcGIS CDN .json requests. 
  • Are you using an interceptor to add a header?

I understand the desire to reduce the on-disk size, but depending on what you find, you may have a good case for sticking with local assets. 

View solution in original post

0 Kudos
10 Replies
AndyGup
Esri Regular Contributor

Hi @Anonymous User  Do stand-alone webmaps load okay directly in your local browser?

0 Kudos
by Anonymous User
Not applicable

outside of an angular app? I have not tried yet. but I did spin up an empty angular 11 app to do some testing (for another project), and I am having the same issue. I will try to spin up a non-angular test app this evening and see if I am still getting the errors

0 Kudos
AndyGup
Esri Regular Contributor

Yes, I meant using the ArcGIS Online MapViewer. For example, can you load this webmap in your browser? https://jsapi.maps.arcgis.com/apps/mapviewer/index.html?webmap=e691172598f04ea8881cd2a4adaa45ba 

0 Kudos
by Anonymous User
Not applicable

ok. Yes, that link works/loads for me in the browser. The odd thing is. this setup was working for ~1 week before I started noticing the CORS errors. I did a couple of days of testing locally before I pushed my code changes to the test site, and it was working there for at least a few more days before the errors started.

0 Kudos
by Anonymous User
Not applicable

so, update on this. my standalone angular app appears to be working correctly now (no CORS errors). so it appears to be isolated to the other, more complex app. I will do some more troubleshooting to see if I can track down what in the application could be causing this. Thanks!

0 Kudos
by Anonymous User
Not applicable

update #2:

I no longer get CORS errors in the standalone app, but I am getting a 'version mismatch' warning:

[esri.core.workers] Version mismatch detected between ArcGIS API for JavaScript and assets:
API version: 4.19 [Date: 20210422, Revision: d399841c]
Assets version: 4.19 [Date: 20210504, Revision: dd3facdb]

but in another app that was recently updated to the 4.19 release, I am getting the CORS errors as well. it appears to be that when the map is behind some sort of (non-esri) login system, it starts breaking?

  • First app - secured behind Azure AD login: CORS errors when using the CDN javascript assets
  • Standalone (testing) app - no 'app-level' security, only ArcGIS Enterprise item access (accessing portal WebMap item - get prompted for ArcGIS credentials on load): no CORS erros
  • Second app - secured behind Okta login: CORS errors when using CDN javascript assets
0 Kudos
ReneRubalcava
Frequent Contributor

On the version mismatch, we a couple of patches, and it just lets you know. Since it's still 4.19, you should be ok. Warnings won't break anything. You can point to the correct version of 4.19 using jsdelivr as described here.

https://community.esri.com/t5/arcgis-api-for-javascript/warning-version-mismatch-detected-between-ar...

0 Kudos
by Anonymous User
Not applicable

Thanks for the info! I wasn't too concerned since it was just a warning and nothing else seemed to be impacted, but wanted to make sure it wasn't some fundamental issue with how I was going about things.

0 Kudos
AndyGup
Esri Regular Contributor

I have a couple questions on the CORS errors. There's nothing in the ArcGIS JS API that should be triggering preflight:

  • Do you know if your secure login system is creating signed URLs? It could be injecting additional header fields into the ArcGIS CDN .json requests. 
  • Are you using an interceptor to add a header?

I understand the desire to reduce the on-disk size, but depending on what you find, you may have a good case for sticking with local assets. 

0 Kudos