ExportWebMap with Secured Services

[deleted-user-Jie3eyjOl9XM]

I'm having trouble using the Print service with services that are secured. When the service is not secure, everything works great. When the service is secure, the widgets work great, and the proxy functions as expected. But, the printing fails. The printing GP service gives me an error that a token is required.

I've create a duplicate of the built-in service, since we define our own templates. My proxy works, so I know that's not the problem. The ExportWebMap service also fails when using the REST API, so that rules out any problem with the JavaScript widgets.

I read somebody say that it matters what account the Print service runs under, because that account needs permission to access the service. But, I don't really understand what that means. But, it seems like the GP service needs to authenticate, or somehow provide a token, or somehow use the proxy. (The exported webmap json doesn not have they proxy in the service URL's)

I'm about to lose it. Does anybody have any other thoughts on what I might try next?

[deleted-user-Jie3eyjOl9XM]

In the REST API, ExportWebWap accepts a token for each operational layer. That's the real problem here. Link to docs:
http://resources.arcgis.com/en/help/arcgis-rest-api/02r3/02r3000001mz000000.htm

However, the json created by the PrintTask widget does not include a token. That makes sense because we are using a proxy page, the proxy page generates the short-lived token.

The new Resource Proxy (https://github.com/Esri/resource-proxy) will accept a single token, and pass it along with the request. But, of course, it will not drill into the WebMapAsJson to include the appropriate token for any layer that matches all the proxy rules. That would be unreasonably complex.

So, here are two (terrible) workarounds:
1) Use JavaScript to get a short-lived token from the proxy, manually build the WebMapAsJson, perhaps extending PrintTask.prototype._getPrintDefinition, to include that token.
2) Create a Python script that accepts the WebMapAsJson, mangles it to include the token, then uses ArcPy.mapping to call ExportToPDF.
Both of those are awfully complex workarounds for something that REALLY should be a part of the platform.


I really hope somebody has been able to use the JSAPI's PrintTask to print a layer from a secured service.

[BjornSvensson]

...Both of those are awfully complex workarounds for something that REALLY should be a part of the platform.

I really hope somebody has been able to use the JSAPI's PrintTask to print a layer from a secured service.

Not sure if you've seen it, but there is a help topic in the server help that talks about "Printing maps that contain secured services":
http://resources.arcgis.com/en/help/main/10.2/index.html#/Printing_maps_that_contain_secured_service...

[deleted-user-Jie3eyjOl9XM · Accepted solution]

Not sure if you've seen it, but there is a help topic in the server help that talks about "Printing maps that contain secured services":
http://resources.arcgis.com/en/help/main/10.2/index.html#/Printing_maps_that_contain_secured_service...

Thanks for that link, Bjorn. I had seen that before, I went through it, and that's what got me rolling in the beginning. But, my secured services were still not working.

After your suggestion, I went back to the help, and banged my head to see what was wrong. The problem was the connections that I was using to connect to the secured services. Get ready for it...
The URL for the connection must precisely match the URL in the webmap json.
Duh? Yes, but in our case, we are using subdomains. So, if the connection is set to http://subdomain1.myserver.com/argis but the webmap json points to a service at http://subdomain2.myserver.com/arcgis then you will not get a match. If the connection is set to http://someservername/arcgis but the webmap json points to a service at http://subdomain1.myserver.com/argis then you will not get a match.

Since we have about 100 subdomains, it's impractical to create 100 connection in ArcCatalog for the Print toolbox. My solution was to create the connection with the server name like http://someservername/arcgis. Then, add a preRequestCallback that changed any subdomain to the server name:

if (ioArgs && ioArgs.content && ioArgs.content.Web_Map_as_JSON) {     var webmapJson = dojo.fromJson(ioArgs.content.Web_Map_as_JSON);     if (webmapJson.operationalLayers.length) {         arrayUtils.forEach(webmapJson.operationalLayers, function (lyr) {             if (lyr.url) {                 try {                     var reString = '[a-z]+.myserver.com';                     var re = new RegExp(reString, "g");                     var newUrl = lyr.url.replace(re, 'someservername');                     lyr.url = newUrl;                 }                 catch (e) {                     console.log(e);                 }             }         }, this);         ioArgs.content.Web_Map_as_JSON = dojo.toJson(webmapJson);     } }

I ran into this same problem using the new JS API resource proxy. Currently, the proxy does not support wildcard subdomains. So, I had to create an entry for each subdomain in the proxy config. That wasn't a big deal for a text file, but much harder in ArcCatalog. So, wildcard subdomains would a nice addition here, too.

[GISDev1]

Thanks for that link, Bjorn. I had seen that before, I went through it, and that's what got me rolling in the beginning. But, my secured services were still not working.

After your suggestion, I went back to the help, and banged my head to see what was wrong. The problem was the connections that I was using to connect to the secured services. Get ready for it...
The URL for the connection must precisely match the URL in the webmap json.
Duh? Yes, but in our case, we are using subdomains. So, if the connection is set to http://subdomain1.myserver.com/argis but the webmap json points to a service at http://subdomain2.myserver.com/arcgis then you will not get a match. If the connection is set to http://someservername/arcgis but the webmap json points to a service at http://subdomain1.myserver.com/argis then you will not get a match.

Since we have about 100 subdomains, it's impractical to create 100 connection in ArcCatalog for the Print toolbox. My solution was to create the connection with the server name like http://someservername/arcgis. Then, add a preRequestCallback that changed any subdomain to the server name:

if (ioArgs && ioArgs.content && ioArgs.content.Web_Map_as_JSON) {
    var webmapJson = dojo.fromJson(ioArgs.content.Web_Map_as_JSON);
    if (webmapJson.operationalLayers.length) {
        arrayUtils.forEach(webmapJson.operationalLayers, function (lyr) {
            if (lyr.url) {
                try {
                    var reString = '[a-z]+.myserver.com';
                    var re = new RegExp(reString, "g");
                    var newUrl = lyr.url.replace(re, 'someservername');
                    lyr.url = newUrl;
                }
                catch (e) {
                    console.log(e);
                }
            }
        }, this);
        ioArgs.content.Web_Map_as_JSON = dojo.toJson(webmapJson);
    }
}

I ran into this same problem using the new JS API resource proxy. Currently, the proxy does not support wildcard subdomains. So, I had to create an entry for each subdomain in the proxy config. That wasn't a big deal for a text file, but much harder in ArcCatalog. So, wildcard subdomains would a nice addition here, too.

Nice workaround, thanks for sharing your code. I'm also wondering what your work needs 100+ subdomains for?

[DaveTimmins]

I've created a basic proxy that will insert tokens into the webmap_as_json request parameter. It's using NancyFx and the code is on GitHub if you want to take a look.