Printing with ArcGIS for Server 10.3

My relationship with the ArcGIS Server Print Service and the REST API was a little more turbulent than expected. Here’s how it all started…

Like many relationships these days, we met online. If you are like me, the Esri JS site is a great place to browse, and hopefully find what you are looking for. And I will admit, this wasn’t my first time. Maybe we moved too fast in the beginning - dinner and some sample code, brunch and a PDF export. It was so easy and comfortable. And that’s when it all started to go sideways.

After a short while, I wanted our relationship to be more secure. We could both print with other people, but I wanted it to be somewhat safe, and dare I say, protected. I looked into some self help books on how to address this and thought I had found a way to take us to the next level. It was a token at this point, short or long, only time and more experience could tell.

This isn’t a new story, we’ve all been down this path before, my Ex, which we can refer to as “ADF”, didn’t print with me for years, but we eventually made a secure connection - but it was already too late as I had stopped using SOAP. But now, things were looking up. A mature [software] package and many RESTful nights had me thinking this was it! Communication was strong, and flexible - but as in all relationships, you really need to work at it. Here are some lessons learned, and where I drop the corny relationship analogies…

Environment Configuration

The workarounds and issues described below are all based on the following:

ArcGIS for Server 10.3 - all patches as of April 10, 2015
ArcGIS JS API 13.3 (latest release as of tests)
Esri DotNet Proxy v1.1 beta
Custom PrintingTools service (to support different layout)

Method 1: Secure Map and Print Service with Long Tokens

If you specify a long token for your app, remember that this will not work with the OTB Print Service directly. The documentation is pretty clear on this, and does explain how to setup a custom print service with credentials.

If you follow the documentation setup for a custom Print service with credentials, you should be up and printing in no time. However, it will only work for 60 minutes on a default AGS installation. More specifically, every thread request will fail after 60 minutes from first request or starting the service. The issue is that the custom service will not request a new token with the stored credentials unless the service is restarted or recycled. After working with support, it is an official bug (BUG-000086183) that will be fixed in 10.3.1. [someone may have already found the bug, but first I heard of it]

If you can’t wait for the 10.3.1 bug fix (which will be release in May), here are two workarounds:

Change the Print Service recycle time to 1 hour to match the default short token time (short tokens are 60 minutes by default). If your recycle time is different, you will need match it to your current setting. If recycle time is <= 60 minutes already, it should already be working without issue.
[or] Modify the maximum length of short-lived tokens in AGS Manager (Security > Token Settings) to match your recycle time. The issue with this approach is that it impacts all short tokens in ArcGIS server, not just this service.

Method 2: Secure Map and Print Service with Short Tokens and Proxy

As I worked with Esri support on the issue above, I decided to play with the short token approach. The documentation for printing with short term tokens appeared to be much easier. No need to embed credentials in a customized print service. However, it didn’t work either?!

If you secure your services using short-term tokens (the default), the user will be challenged to provide the name and password upon opening the web app. The token is then passed to the PrintingTools service when the user requests a map to be printed. There is no need to create a custom print service (as described below) if you are using short-term tokens. ~ Esri help

Confused, since the help says “there is no need to create a custom print service…”, I thought I found a second bug in as many days. But reading it again, the kicker is that a “user will be challenged to provide the name and password”. If a user provides the credentials, yes, it will work. My setup using the proxy with short tokens was the culprit. I don’t want users to provide passwords - Now what?

The current version of the proxy (1.1b) will request a token to access the secure map and print services which works great for the JavaScript application. However, since the proxy sends referer information, the token is tied to that referer (even if your proxy and AGS are on the same server). Although not an issue for application, it is a big issue for the Print Service since it will send its own request for a map without a referer - so the request is rejected by the map service. [If my spelling of “referer” appears wrong, here is a short history on the typo.]

So how do I use short tokens in the application yet still use the ArcGIS Server Print Service without users typing in passwords - here are a few workarounds:

Use the custom print service with credentials stored for printing from Method 1, and a short token for the application via the proxy. It’s a hybrid, but it works (must also implement one of the workarounds previously mentioned).
[or] Modify the proxy. Some C# Kung Fu and you can remove the referer as short tokens don’t require one be provided. Although the downside is you will be out of the loop for any fixes/updates to the Esri version.
[or] Surrender the approach and have users authenticate in the app. The downside is that your users are required to have a user/pw. Pro is that you can control access and use the short token approach.

Just wait until users have 3D printers!