Our Chrome web browsers happened to update overnight to version 142.0.7444.60. Now, whenever we try to access an WAB using the Classic Web Map Viewer (or any map using the Classic Web Map Viewer), none of our hosted layers are available. Everything is visible and functional still if you open the map in the new Map Viewer, but anything build with Classic seems to be broken atm.
We still haven't finished converting all our WAB applications over to Experience Builder yet, as I had assumed they would continue to work until next spring.
Solved! Go to Solution.
It is. Trust me.
yes this solved my issue, thank you!
This is impacting all services in web maps consumed by our EAM solution. Dashboards, surveys, and Experience Builders are also affected, and field staff are now reporting issues accessing data.
I've been working on a similar problem this afternoon. Only in updated Chrome browser several of our imagery basemaps weren't displaying. Enabling "local network access" (either from pop-up, or "site information" icon to left of URL) resolves problem.
I'm guessing that AGOL apps are referencing what Chrome sees as the local network. This is a broad list, I'm guessing a local loopback may be to blamed, but unsure. See: https://wicg.github.io/local-network-access/#non-public-ip-address-blocks
Hello @JackBovee,
This behaviour is due to an update in the way Chrome handles Local Network Access checks. You can read more about that update here: https://developer.chrome.com/blog/local-network-access.
For the time being, until the issue is fixed by Esri, you can utilize the following workaround. To avoid the inconvenience of having to constantly block or allow Local Network Access, you can go to chrome://flags/ and set Local Network Access Checks from Default to Disabled, which restores the behavior prior to the Chrome 142.x update.
Please feel free to reach out if you have any further questions!
Charles Blanchard
Associate GIS Analyst
Esri Canada
Hi Charles,
Can I please get an update on this? Our organization is seeing this issue where users accessing resources from sites on the arcgis.com domain are being prompted to allow the site to connect to devices on our local network.
We have opened a support request with ESRI only to be told that we need to create an exception to this security policy, with no further explanation provided. As a member of our organization's security team, I need to understand the rationale for your service to require this access.
Thanks!
Ryan
@Charles_Blanchard , are you able to answer my question, or is there someone else I can reach out to?
Hello Ryan,
My apologies for the delay in my response.
A general overview of the effect of the Chrome and Edge updates to the Local Network Access specification on ArcGIS Online and ArcGIS enterprise can be found at this link: https://support.esri.com/en-us/knowledge-base/what-to-know-about-new-permission-prompt-in-google-chr....
This article discusses the three main implementations of the software that require CORS requests to internal servers, these being:
The key component here is the CORS requests to internal servers, which are a crucial component of the above functionalities. Unfortunately, these requests are now flagged by default by the new LNA specification, and thus bring up the prompt for end users.
For the time being, the LNA Adoption Guide provided by Google is an excellent resource to make the transition easier, and the article I linked above also includes this snippet from that guide specific to iFrames:
Add the local-network-access string to the iFrame configuration. This will ensure that the expected CORS request is sent out to the Enterprise portal for verification.
<iframe src="domainB.example" allow="local-network-access ‘DOMAIN’"></iframe>
I apologize for any inconvenience this problem has caused. Please feel free to reach back out if you have further questions, and I will do my best to address them.
Thank you,
Charles Blanchard
Associate GIS Analyst, Esri Canada
Hi Charles,
Is there a bug for this that we can follow? Just looking for confirmation that ESRI is aware and is working on a fix.
Thanks,
Jennifer