Good morning ESRI community,
I am reaching out to you because I am having issues with a lot of my webmaps in my arcgis Enterprise 11.4. We have a federated deployment with ArcGIS Server. Here is a more detailed description of the behaviour and what we have tried:
Problem description
The Settings page of many existing web maps on the spatial portal has become inaccessible. This are the settings inside the item (next to "Overview"). When attempting to access the settings page via the portal user interface or the URL, it gets stuck on the load screen:
The first 2 errors (“syntaxError” and “code:403”) occur after opening the item in the portal. The last error (“Uncaught (in promise) TypeError”) occurs after trying to open the Settings of the item
What we have tried
Tried reindexing the portal (Full)
Tried validating the JSON files in item files using python. Didn’t detect any errors.
Tried accessing the content of the settings page (of a broken web map) using ArcGIS Python API to try and detect errors or corruption. The content returned without any errors.
Inspected Arcgis Server logs in DEBUG mode:
For both faulty and working webmaps I keep getting a 403 error for each layer in them. This is one example of only one layer:
Exception in authorize Token Required A request was made for service 'Reference/Water_Points_Natural_editing.MapServer' but it did not have adequate credentials. /arcgis/rest/services/Reference/Infrastructure_Points_editing/FeatureServer/0 Exception in authorize Token Required GetServiceInFederatedMode returned null. Error 403.
A request was made for service 'Reference/Water_Points_Natural_editing.MapServer' but it did not have adequate credentials. /arcgis/rest/services/Reference/Infrastructure_Points_editing/FeatureServer/0 Exception in authorize Token Required GetServiceInFederatedMode returned null. Error 403. /arcgis/rest/services/Reference/Water_Infrastructure_Points_editing/FeatureServer/2
However, this only translates into an error in the faulty maps when inspecting the devtools in chrome. Thus, it is possible that a good webmap somehow manages this gracefully, while the faulty ones have some sort of corrupted file (maybe a JSON as suggested by chrome devtools console)
Some additional info:
The faulty webmaps were created about 2 years ago, and they all have offline areas associated with them. They had not displayed this behaviour before, and are still accessible when you visualise them in mapviewer.