topic Re: Channel Security Error from MapManager in ArcGIS Viewer for Flex Questions

Channel Security Error from MapManager

DavidGraves — Fri, 27 Jul 2012 16:15:20 GMT

I've recently installed ArcGIS Viewer for Flex 3, and have built several applications with it. We've configured these to be served up from a web server outside our firewall, which accesses the server inside our firewall where Flex Viewer is installed and the REST services are generated.

Everything works just fine via the outside URL when we test it from within our organization, but when others outside our organization attempt to view any one of the sites, their browser properly loads up the page and base layer, but does not load the application layers that we have generated via REST services. Instead, it returns a MapManager error "**** layer failed to load: Fault Code: Channel.Security.Error, Fault into: Security error accessing url, Fault details: Destination: Default HTTP".

I've placed the crossdomain.xml file into the web root directories of both the server with flex viewer (at C:\Program Files (x86)\ArcGIS\Server10.0\java\manager\web_output), and the server outside the firewall (at C:\inetpub\wwwroot), but the problem still persists so I am unsure what to try next.

Thanks very much for any feeback!

- David

Re: Channel Security Error from MapManager

DavidGraves — Fri, 27 Jul 2012 20:09:17 GMT

I should also mention that the server outside our firewall is set up as reverse proxy for the interal server running Flex Viewer. On the internal server, I've additionally saved crossdomain.xml to both the web root folder (C:\inetput\wwwroot) and the proxy output folder (C:\arcgisserver\proxyoutput). The URL "http://server/crossdomain.xml" succeeds in showing the crossdomain file when tried on both the internal server, and the outside (reverse proxy) public domain.

Re: Channel Security Error from MapManager

RobertScheitlin__GISP — Fri, 27 Jul 2012 20:19:17 GMT

David,

You need to use a http tool like fiddler to see what requests are not coming back properly. I have a reverse proxy setup inside my DMZ and I use Apache for my reverse proxy and have a copy of my crossdomain.xml in my htdocs (the same as a wwwroot folder).

Re: Channel Security Error from MapManager

DavidGraves — Sat, 28 Jul 2012 00:42:50 GMT

Thanks Robert - that's very helpful.

I installed Fiddler and tested a couple of the sites with Fiddler running. The only thing shown in red, which I assume is a failure, was indeed a call for the crossdomain.xml on the internal server, where flex viewer is installed. It is looking for it as /crossdomain.xml under server:8399. My REST services are delivered via port 8399 as per the default installation of ArcGIS Server.

However, I'm still unsure where the crossdomain.xml file needs to be found. I've saved it in the web root folder, where the flex output is created, and it does show up when I browse to http://server/crossdomain.xml. I suspect it has something to do with the port (8399) where the REST services are delivered (?)

Re: Channel Security Error from MapManager

RobertScheitlin__GISP — Sat, 28 Jul 2012 00:53:06 GMT

David,

Be sure that your Flex Viewer URLs in your main config.xml are using the reverse proxy urls.

In my case I have a couple of ArcGIS Servers inside the firewall. Lets same for example
http://GISServerA:8399/ArcGIS/Rest/Services
and
http://GISServerB:8399/ArcGIS2/Rest/Services

I would not use those urls in my main config.xml I would use the reverse proxy urls of
http://gis.calhouncounty.org/ArcGIS/Rest/Services
and
http://gis.calhouncounty.org/ArcGIS2/Rest/Services

And once again I have my crossdomain.xml on my reverse proxy server in it's main web folder (htdocs) and that is what get served when a request for http://gis.calhouncounty.org/crossdomain.xml is received. I do not have a proxy pass on my reverse proxy server for my crossdomain.xml at all.

Hope this helps.

Re: Channel Security Error from MapManager

BjornSvensson — Sat, 28 Jul 2012 16:57:10 GMT

However, I'm still unsure where the crossdomain.xml file needs to be found.

The "Deploying an application" API help topic tries to explain that: http://resources.arcgis.com/en/help/flex-api/concepts/index.html#/Deploying_an_application/017p00000019000000/. See the "Deploying crossdomain.xml" section. In your case, for Java:

Java�??Add crossdomain.xml to <ArcGIS_Server_Install_Location>\ArcGIS\java\manager\web_output for 10.0 or <ArcGIS_Server_Install_Location>\ArcGIS\java\web_output for 9.3 installations of ArcGIS Server. On Windows, the default locations for these directories are as follows:
10.0�??C:\Program Files\ArcGIS\Server\java\manager\web_output
9.3�??C:\Program Files\ArcGIS\java\web_output

And like Robert mentions if you are using a proxy server, then it would go there. Basically whatever URL your application tries to access it, is what needs the crossdomain.

Re: Channel Security Error from MapManager

DavidGraves — Mon, 30 Jul 2012 16:52:39 GMT

David,

Be sure that your Flex Viewer URLs in your main config.xml are using the reverse proxy urls.

In my case I have a couple of ArcGIS Servers inside the firewall. Lets same for example
http://GISServerA:8399/ArcGIS/Rest/Services
and
http://GISServerB:8399/ArcGIS2/Rest/Services

I would not use those urls in my main config.xml I would use the reverse proxy urls of
http://gis.calhouncounty.org/ArcGIS/Rest/Services
and
http://gis.calhouncounty.org/ArcGIS2/Rest/Services

Thanks Robert. However, when I change the config.xml to use the reserve proxy url (map.critfc.org/arcgis/rest/services) instead of the internal url (giserverA:8399/arcgis/rest/services), the problem persists and now also occurs internally as well as externally, with Fiddler returning a '404' error for "/arcgis/rest/services/LowerColChum/MapServer?f=json"

Re: Channel Security Error from MapManager

RobertScheitlin__GISP — Mon, 30 Jul 2012 17:02:34 GMT

David, Not sure what to tell you now... You have something setup improperly in your reverse proxy configuration. Did you follow this page? http://support.esri.com/en/knowledgebase/techarticles/detail/35894

Re: Channel Security Error from MapManager

DavidGraves — Mon, 30 Jul 2012 17:02:50 GMT

And like Robert mentions if you are using a proxy server, then it would go there. Basically whatever URL your application tries to access it, is what needs the crossdomain.

Thanks Bjorn - I have tried to place the crossdomain.xml file where I think it should go, actually placing it in several folders to be safe, including C:\Program Files (x86)\ArcGIS\Server10.0\java\manager\web_output.

It seems that an external browser is not finding it (crossdomain.xml) when the reverse proxy address is used to access the REST services. So, I guess what I can't figure out is where to save the crossdomain.xml file so that this example reverse proxy URL will work:

http://map.critfc.org/arcgis/rest/services/LowerColChum/MapServer

Re: Channel Security Error from MapManager

DavidGraves — Mon, 30 Jul 2012 18:46:18 GMT

David, Not sure what to tell you now... You have something setup improperly in your reverse proxy configuration. Did you follow this page? http://support.esri.com/en/knowledgebase/techarticles/detail/35894

We used a similar set of instructions, based on the java version of ArcGIS for Server. We do have the virtual directories and routing rules set up correctly. I had not, however, changed the server.properties or rest-config files to point to the reverse proxy.

Unfortunately, when I try this I only get a slightly different error from the MapManager when trying to load the page externally. It now says "**** layer failed to load: Fault Code: Server.Error.Request and shows a Fault Details of an "ioError" with the URL http://map.critfc.org/arcgis/rest/services/layer/MapServer?f=json

I'm a bit stumped as the reverse proxy works fine from inside our firewall and loads the REST services just fine through this reverse proxy. We only run into the error from a computer outside our network, where the reverse proxy does not seem to work for the REST services (but the page and base layer load fine via the reverse proxy). I think we may try to test our firewall a bit to see if a closed port is blocking the services.