Esri client accesses invalid URLs when trying to render map

348
4
01-11-2019 12:19 AM
alehmann
New Contributor III

Yesterday we encountered the following problem on a customer's system: During loading of the map, the runtime makes calls to URLs that are not part of the Web Adaptor / ArcGIS Server. This leads to problems when access to invalid URLs is replied to with a 403 status code.

The setup is as follows:

The map service that's configured as endpoint for our app is like this:

https://arcgis.<customer>.com/<webadaptor>/rest/services/<app_service>/MapServer

During loading of the map, the runtime makes a call to

https://arcgis.<customer>.com/rest/info?f=json

Note the missing "<webadaptor>" part. Our customer's infrastructure is set up so that requests to invalid URLs (the URL without web adaptor is not mapped) result in a 403 response. Apparently the runtime then thinks that the user is not authorized to view the map and fails the load.

On our own internal system we were able to see the same pattern of requests with the difference that our system does not respond with a 403 on invalid urls but a 404 - which seems fine for the runtime as it then calls the correct url right afterwards.

Our app is a Xamarin.Forms app using the 100.3 release of the runtime.

Is this documented behaviour or a bug in the runtime? We might be able to convince our customer's IT in this case to either forward the /rest path to the web adaptor or change the response to a 404 but they are a bit "surprised" (to put it mildly) that our app is accessing paths it is not supposed to.

We would appreciate any guidance on this on how to make sure our app only accesses ArcGIS resources - maybe this is fixed in 100.4 already?

0 Kudos
4 Replies
dotMorten_esri
Esri Frequent Contributor

I'm browsing through the code where this info call occurs, and it _should_ handle the <webadapter> portion just fine. However there does seem to be a special case where a manual server registration would be used, without the webadapter part. Do you register your service manually?

Also could you share the full url used by the secured service? That might help me better understand why it ends up skipping the webadapter portion of the URL.

0 Kudos
alehmann
New Contributor III

We do register the service manually with 

authManager.RegisterServer(new ServerInfo { ServerUri = new Uri(serverUrl) });

where `serverUrl` points to the web adaptor (i. e. https://arcgis.customer.com/webadaptor in the example above).

By full url do you mean the real url of our customer? I could share that in private if that's any help. Otherwise, the above is it essentially - the service is not in any subdirectory - i.e. it's reachable via https://arcgis.customer.com/webadaptor/rest/services/app_service/MapServer

Our customer's IT now returns a 404 on the /rest/info?f=json request and allows the /webadaptor/rest/info?f=json request as well. We are still getting the same exception saying that the user is not authorized to access the service. Which is definitely not the case as we are accessing that very same service to talk to our SOE which is working just fine (with the same credentials).

The process right now looks something like this: First we talk to our SOE to get the configuration for our app at runtime (stuff like other services to display, business logic etc). When we've done that, we want to load the configured map - which is where we get these errors. To talk to our SOE we do not use the ArcGISHttpClient but our own custom HttpMessageHandler which (amongst other things) handles authentication itself.

This error happens on iOS, Android and UWP - so this doesn't seem to be related to which network stack is used.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

Could you try register the server with the /rest/services/ part? Ie. 

authManager.RegisterServer(new ServerInfo { ServerUri = new Uri("https://arcgis.customer.com/webadaptor/rest/services") });

0 Kudos
alehmann
New Contributor III

I will try that. 

In the meantime is there anything we can do on our end to avoid the error that the client thinks it's not authorized to access the map service?

0 Kudos