A .Net Core Proxy for ArcGIS Server Resources

For the past year and a half, I've been working on a large GIS web application. At its backbone is ESRI technology. Here is a brief overview of our tech stack.

ArcGIS Server hosts service endpoints that are the API for our client application. The application is built with ASP.Net MVC and houses an Angular SPA. The MVC part of the application hosts a proxy . The proxy enables secure communication with the ArcGIS Server.

The ESRI Resource Proxy was written a while back. It's packaged in a .ashx file with several methods going beyond a hundred lines of code. While there is no doubt that this is a marvel of ingenuity it's glory days where likely over 10 years ago. You don't have to read far before realizing that some very basic refactoring would do this proxy a world of good.

Early in development of our system, I had forked and modified the proxy. We had some issues in our environment that the proxy couldn't handle. With OAuth2 flows the proxy assumed that the token endpoint would allow anonymous traffic. When ArcGIS Server used Integrated Windows Authentication (IWA) to secure the token endpoint, the proxy does not pass credentials. This a generally reasonable assumption, but not true in our environment. I forked the code and set about to fix it.

In the process I discovered several other issues. One such issue was the code calling an authorization endpoint with incorrect parameters. The code doesn't have unit tests. Reading the issues section on Github makes one loose confidence in all 1250 lines of proxy code. Now that I've presented a picture of the code quality, lets get into the more bizarre.

ESRI products aren't open source. The license costs are rather high. If you build an application with ArcGIS server and a client side code, as of now you need the proxy. It is not an optional chunk of the stack.

ESRI has taken the position on Github that the proxy is a community supported effort. Furthermore, they have stated that they will not be creating a proxy for .net core. Not much point to customer support when you have a monopoly.

We migrated our code from full framework to ASP.Net core. In the process I did something the ESRI team should have done. I wrote a resource proxy for .net core. You can find it on Github and as a NuGet package.

The .Net Core proxy includes a built in memory cache. If you are running a load balancer, fork the project and replace the cache provider. Or submit a PR to make the cache provider configurable. :) The code has unit tests, and uses the new HttpClientFactory in .Net Core.

If you can manage getting away from ESRI products do it!

Happy Coding!

(Update): ESRI has since updated their Github proxy page to outline new approaches. Though they don't give enough information to really understand what any of the approaches mean.