Message asking for access to local device when opening organization-shared maps

MathiasHudock · ‎10-30-2025

Some members of my organization have been seeing the below message when viewing Organization-shared web maps and web experiences in AGOL, specifically while using the Chrome browser:

This message doesn't seem to be related to a specific user type; two of our users have the same user type and role, but one gets the message, and the other doesn't. It also does not appear when viewing publicly-shared items. Has anyone seen this kind of thing before?

Justin_Greco · ‎10-30-2025

This is due to a security change in the latest version of Chrome:

https://developer.chrome.com/blog/local-network-access

This is affecting only our staff that are on the city network and only affecting services being served through our web adaptor. I believe the issue is that our web servers resolve to a local IP address while connecting from our network. It is not affecting anyone connecting from outside our network.

You can disable it in Chrome all together by going to chrome://flags/#local-network-access-check and switching the setting to "Disabled".

TravisColeHC · ‎10-31-2025

This just started happening to our county Map Viewer. It has major impacts on the functionality of the Experience Builder app. If you just close the pop-up or hit block, at the very least, our geolocator and print services stop functioning in the app. I haven't tested other functionality yet, but I suspect there are other things that also don't work properly.

Justin_Greco · ‎10-31-2025

We decided to just send out communication to all our users stating that it is safe to select allow as a short term solution. The long term fix will be for our IT to set this enterprise Chrome policy:

https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls

I don't know if there is something Esri can do about this, I do see that we can access our local network from the Map Viewer at www.arcgis.com, so I am thinking there must be something on their end allowing it, so maybe the same can be done to experience.arcgis.com.

The biggest issue for us has been our custom JavaScript applications hosted on our web servers.

DanielMarcolesco

We were having issues connecting to imagery services on a local network when using online maps. Clicking "Allow" on the "Look for and connect to any device on your local network" fixed the issue for us. This permission can also be corrected when "Block" is clicked by clicking the "View site information button" to the left of the URL, toggling on "Local network access", then reloading the page.

Todd_Metzler

Our organization has also been affected by this. We have chosen to notify our users of the problem, advising users to NOT "Allow" and interact with Web GIS using MS Edge or Firefox while our client tech team enables an enterprise fix. Unlike some of the solutions already posted, our organization's web browser configuration are controlled by policy so individual user initiated changes to browser settings isn't a workable solution. Web GIS troubleshooting 101 here. Has the perceived problem been tested in more than one browser? Is the result repeatable in more than one browser? Yes, we can accept that Chrome is likely the most popular browser. Sometimes it doesn't get the job done for WEB GIS.

TravisColeHC

Unfortunately, this appears to be another “just-deal-with-it” situation from both Google and Esri. Google has published a blog explaining the issue here: https://developer.chrome.com/blog/local-network-access

In short, Google recommends either:

Implementing an agency-wide policy to allow access to experience.arcgis.com, or
Instructing users to manually click “Allow” when prompted.

So far, the prompt seems to appear only for users on the same local network as the data being accessed. In our case, most of the utilities and datasets are hosted in our Enterprise geodatabase. Even though our Experience Builder app is hosted on ArcGIS Online (AGOL), denying access blocks not just the print utility and geolocator, but also any datasets used from our Enterprise REST services in the app.

I went back and forth with Chrome developers, and they confirmed this is expected behavior. However, they were curious why Experience Builder was triggering the prompt in the first place, as accessing local storage in this way is considered atypical.