Sunday, August 26, 2018

A .Net Core Proxy for ArcGIS Server Resources

Allow me to first set the stage... For the past year and a half, I've been working on a large GIS centered web application. ESRI technology powers our GIS stack with ArGIS Server hosting service endpoints. The application is an ASP.Net MVC application that houses an Angular SPA. The MVC application hosts the ESRI resource proxy enabling secure communication with the server.

Opening the code for the .Net version of the proxy on GitHub, several things become clear. The code feels intimidating at 1250 lines. It's packaged in a .ashx file with several methods going beyond a hundred lines of code. There are methods to serialize objects to JSON, as well as methods to retrieve values from JSON. Below is an example.
    private string getJsonValue(string text, string key) {
        int i = text.IndexOf(key);
        String value = "";
        if (i > -1) {
            value = text.Substring(text.IndexOf(':', i) + 1).Trim();

            value = value.Length > 0 && value[0] == '"' ?
                // Get the rest of a quoted string
                value.Substring(1, Math.Max(0, value.IndexOf('"', 1) - 1)) :
                // Get a string up to the closest comma, bracket, or brace
                value = value.Substring(0,
                            indexOf_HighFlag(value, ","),
                                indexOf_HighFlag(value, "]"),
                                indexOf_HighFlag(value, "}")
        return value.Replace("\\/", "/");

While there is no doubt that this is a marvel of ingenuity and genius, 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.

When I realized I'd need to use the proxy, I pulled the code off Github, installed, configured and forgot about it. For a day or two... 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 IWA to secure the token endpoint the proxy does not pass credential. 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. Unit tests are not present in the code base. Reading the issues section on Github makes one loose confidence in all 1250 lines of code.

Now that I've presented a picture of the code quality, lets get into the more bizarre. ESRI licenses products for large quantities of money. If you want to secure your data while still exposing it to a client application, your likely going to need a proxy.

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. I guess there is no point to customer support when you have a monopoly.

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 base contains unit tests, and uses the new HttpClientFactory in .Net Core.

If you are moving your GIS application to .Net Core and are in need of a proxy, try the ArcGIS Server resource proxy for .Net Core.

No comments:

Post a Comment