Web-adaptor print service URL not printing AGOL secured layers

1367
3
Jump to solution
08-06-2020 03:30 AM
KellieH
New Contributor II

I have made a custom print service for my webapp. All of the layers in this webapp are hosted on AGOL and are shared to specific access groups - but they are not public (this is by design and the layers display perfectly to all group members in the app). The custom print service is hosted on my organization's arcserver.

This arcserver has a webadaptor URL that is configured via a reverse proxy.

I am using the WAB print widget.

Using the print widget with the web adapted print service URL returns "Error try again[...]execute status 0" if any secured layers are displayed in the app when the print service is called. It WILL process if all of these secured layers are turned off.

However, when I run the print widget with the internal print service server URL - it prints as it should and all the secured layers display properly without any errors.

I have read dozens of threads and blog posts on printing secure layer to try to fix this, but nearly all of these refer to storing credentials for the servers that the secured layers are hosted on with the print service - but since all of my layers are stored on AGOL, this does not seem like a valid solution for me (and also the print service executes successfully pre-webadaptor).

My guess is that for some reason the web-adapted service URL is not receiving/properly handling the access token for these secured layers but I have no idea what modifications should be made on the server to troubleshoot this.

Does anyone have any ideas on how the fix this? People external to my organization need to use this application so keeping the internal URL is not an option.

Thank you!

0 Kudos
1 Solution

Accepted Solutions
KellieH
New Contributor II

I have partially resolved this issue. 

It turns out that my print service errors only looked like they were caused by secured layers because all of my layers were secured. 

What was actually happening was our reverse proxy was not configured to handle larger POST requests, and that is why the internal server URL would work but the web adapted URL would always return an error. We increased the size limit on the reverse proxy and now the export web map task will process as expected externally....most of the time.

I am still getting errors on larger POST requests and this is almost certainly caused by needing to increase the post limit on the arcserver itself (see - https://community.esri.com/thread/72208 ). We haven't done this yet, but hopefully if/when we do it will resolve the issue with the larger requests.

View solution in original post

3 Replies
CarlosNantes
New Contributor III

Can you confirm the token is been sent to Print Service in the body of the POST request?

You can verify that by opening chrome developer tools in your google chrome browser an open the headers tab to confirm the presence of this token paremeter.

IdentifyManager module can be used to register the token using arcgis js api. After registering it, it should be sent with the requests you make to arcgis services. Use esriId.registerToken() function. 

KellieH
New Contributor II

Thank you for your reply!
Yes the token parameter is within the body of the POST request for both URLS.

With the web-adapted URL I also get this error: "Status 413 Request Entity Too Large", this error is not present with the internal URL. 

0 Kudos
KellieH
New Contributor II

I have partially resolved this issue. 

It turns out that my print service errors only looked like they were caused by secured layers because all of my layers were secured. 

What was actually happening was our reverse proxy was not configured to handle larger POST requests, and that is why the internal server URL would work but the web adapted URL would always return an error. We increased the size limit on the reverse proxy and now the export web map task will process as expected externally....most of the time.

I am still getting errors on larger POST requests and this is almost certainly caused by needing to increase the post limit on the arcserver itself (see - https://community.esri.com/thread/72208 ). We haven't done this yet, but hopefully if/when we do it will resolve the issue with the larger requests.