In my role at Esri Australia resolving Enterprise and Developer support issues, there’s rarely a day that goes by where it’s not immensely useful to investigate communication between the different parts of a system. When a component of a GIS is not behaving as expected, forming a complete picture of the behaviour across the system is often instrumental in understanding the underlying cause. This article will focus on the special case of intercepting HTTP requests generated by applications running on top of Microsoft IIS, such as ArcGIS Web Adaptor and the Esri Resource Proxy.
A valuable tool for investigating the communication between components of an Enterprise GIS is Fiddler. If you’re not familiar with Fiddler, it’s a web debugging tool that logs the HTTP traffic going in and out of a computer, enabling us to review the communication for troubleshooting purposes. If you’ve never used Fiddler before, I recommend that you familiarise yourself with its use by checking out Using Fiddler to Troubleshoot ArcConundrums, which illustrates the process of using Fiddler to troubleshoot connection issues between ArcGIS Desktop and ArcGIS Online.
Once equipped with a basic understanding of the software, in most cases Fiddler is straightforward to use – we fire it up, run the process we want to check on, and watch the HTTP traffic roll in. It’s not always that simple though. One such case where things get a bit more involved is when we want to intercept HTTP requests being made by IIS to another component of the GIS. This could be when a Web Adaptor running on is communicating with an ArcGIS Server or Portal for ArcGIS instance, or if we have an Esri Resource proxy running on IIS that is making requests on the behalf of a web application. In these situations, if we take the usual approach of starting Fiddler on the machine making the requests that we want to monitor and wait for the traffic to start appearing on the screen – we’ll be disappointed to find that Fiddler won’t be able to see any of the requests being made by IIS to other parts of our GIS.
Say for example we have a publicly accessible web mapping application that needs to access data from a secured ArcGIS Online Hosted Feature service. We don’t want to make the service public, or give the end user credentials to log in to our ArcGIS Online organisation. This is an ideal situation for using the Esri Resource Proxy to transparently embed credentials into requests to the secured service, in a way that the credentials are never exposed to the end user.
So we get to the point where we’ve installed and configured the Esri resource proxy on an IIS web server, and for at least one of the services being consumed by our web mapping application , the proxy works as expected. The web application makes a request for the secured service, this request goes through the proxy we set up on our web server, the proxy injects the appropriate credentials and forwards it onto ArcGIS Online. ArcGIS Online responds to the request coming from the proxy, and the proxy forwards this response on to the web application and the browser displays the map as expected.
What do we do if we are attempting to add another secured service into the web application, and find that it’s not working? The first step would be to examine the traffic between the web application and the proxy. If we see that the request being made by the web application is correct but the proxy is returning an error, this tells us there’s a problem between the proxy and the service. In this situation, the first order of business would be to go back and check the proxy’s config. If there are no obvious problems in the config ,it can be useful to observe the communication taking place between the resource proxy and the service.
Fiddler works by setting itself up as a HTTP proxy for the machine it’s running on, forcing HTTP traffic to pass through Fiddler before Fiddler forwards in on to intended recipient. This arrangement allows Fiddler to monitor the flow and contents of HTTP traffic being processed by applications on the computer. When we’re working with IIS though, it’s not going to use the proxy that Fiddler sets up, unless it is explicitly told to do so. The way we tell something running on IIS to go through a proxy is using a web.config file.
The IIS configuration system delegates a lot of configurability to web.config files, which allows for independent control over settings for individual sites, applications, and directories hosted on IIS. This means we can create a Web.config file in the folder containing the proxy (or Web Adaptor for that matter) and only that specific hosted application will be affected. This is important as it allows us to drop in a web.config file routing traffic through Fiddler into the folder containing the Esri resource proxy, while any other applications or sites hosted on the same server remain unaffected.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.net> <defaultProxy enabled="true"> <proxy proxyaddress="http://localhost:8888" /> </defaultProxy> </system.net> </configuration>
Using the Esri resource proxy, Fiddler and a web browser all running on the same machine we can make a request through the proxy and see the entire flow of communication returned in Fiddler.
To start with, I have a proxy.config file set up to allow access to my secured ArcGIS Online service using OAuth2 authentication. The key parts of the proxy.config for this scenario consist of a URL pointing to a secured ArcGIS Online hosted feature service, along with authentication being provided by a clientId and clientSecret which was obtained from an application hosted within my ArcGIS Online organisation.
Now in a web browser a request is made to a secured service through the proxy page. In the screenshot below, the first session (row) shows the browser’s request to the proxy, the second is the proxy authenticating with ArcGIS Online, and the third is the proxy passing the original request from the browser through to ArcGIS Online.
In this particular instance, , the web browser shows a “token required” message indicating that something is misconfigured.
What we’re seeing in the web browser is the result of the service request being made to ArcGIS Online. Given that we seem to be missing a token, it would be useful to see how ArcGIS Online responded when the proxy attempted to obtain a token. With the Esri Resource proxy setup to send traffic through Fiddler, this becomes simple to observe.
Now we can see that ArcGIS Online was unable to provide a token, due to the client ID specified in the OAuth2 request being invalid.
Going back and checking the client ID of the ArcGIS Online application being used for OAuth2 authentication, I noticed a mistake was made when copying and pasting the information into the proxy.config. After correcting this mistake, the proxy worked as intended.
In this article, we have demonstrated how to configure an application running on IIS to route its traffic through the Fiddler web debugger. This provides us with the valuable troubleshooting ability to expose and observe back-end traffic exchanged by components of an ArcGIS platform running in Microsoft IIS.