Let's say a flex application is hosted on Server #1. While hosted on
Server #1, remember that the Flex/Flash application actually runs and
executes on a client machine. The requests are coming from the client
machine, not the server.
Now think about if the flash application happens to be executed on a client
machine within the same internal network as Server #2. Server #2 is an
intranet server and is designed only to answer requests from its internal
network. But the Flash app IS executing on its internal network, even
though it was hosted (just the code, essentially) on Server #1.
The flash app can then make requests to Server #2 and send all of the
information back to Server #1 (or wherever it wants), even though Server #1
would never have been allowed access in the first place. This is sort of
self-enforcement by Flash to prevent this sort of thing.
It's the Flash application that is enforcing the need for the
crossdomain.xml file. It forces server #2's admin to say ... yes ... if
there is a flash app running on my network but that was hosted elsewhere,
it's ok for that app to access my data.
--
D. Michael Grogan
-----------------------------------------
STG, Inc. - Government ContractorData Access & Applications Branch
Climate Services and Monitoring Division
National Climatic Data Centermike.grogan@xxxxxxxx
Phone: (828) 271-4680
Fax: (828) 271-4876
Mobile: (865) 235-1364
On Wed, Aug 15, 2012 at 12:38 PM, Lansing Madry <madry@xxxxxxxxxxxxxxxx>wrote:
> On 8/15/2012 10:18 AM, Jay Alder wrote:
>
>> Cross domain files are used by Adobe products like Flash and Flex to add
>> some security to which hosts can access your server. I use thredds services
>> within Flex applications we've developed in Adobe Flex to visualize climate
>> model data. To be able to use Flash/Flex with Thredds services you need to
>> have a cross domain file installed on the same machine that hosts the
>> thredds web application.
>>
>> It should be installed at ${tomcat_home}/webapps/ROOT/**crossdomain.xml
>>
>> There are lots of variations on what you can put in the cross domain
>> file. The sample one the developer attached basically says any host can
>> connect to this server (with Flash/Flex applications). There have also been
>> some changes on the cross domain syntax from Flash Player 9 to Flash Player
>> 10.
>> http://www.adobe.com/devnet/**flashplayer/articles/fplayer9_**
>> security.html<http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html>
>>
>> As an example, here is our working cross domain file.
>>
>> <cross-domain-policy>
>> <site-control permitted-cross-domain-**policies="master-only"/>
>> <allow-access-from domain="*.coas.oregonstate.edu**"/>
>> </cross-domain-policy>
>>
>> Since we host the thredds server and the Flex web applications on the
>> same machine, I lock down access to only allow hosts within the
>> coas.oregonstate.edu domain. This means Flash/Flex web applications
>> hosted on yourdomain.com can not access our thredds services (primarily
>> WMS for mapping applications).
>>
>> If any of you Thredds gurus are interested, here is a link to our Adobe
>> Flex web application that maps climate model data via Thredds WMS.
>> http://regclim.coas.**oregonstate.edu/visualization/**
>> rcd/regional-climate-**downloader/index.html<http://regclim.coas.oregonstate.edu/visualization/rcd/regional-climate-downloader/index.html>
>>
>> Hope this helps.
>>
>> On 08/15/2012 09:01 AM, Roy Mendelssohn wrote:
>>
>>> For what it is worth, I went to the URL where he claims to be getting an
>>> error, and it worked just fine. The file he sent I believe would open up
>>> all javascript cross-doman requests. Not certain that is something you
>>> want on your server, in particular because I can't replicate his error.
>>>
>>> It is possible that there is an error in the next steps after the
>>> GetCapabilites request, but I would ask him to provide specific examples of
>>> that. Unless you are doing proxying to a different machine in your
>>> thredds, I don't know why a cross-domain request would be made. I ran into
>>> this problem with ncWMS, but that was because we were indeed proxying.
>>>
>>> -Roy
>>>
>>> On Aug 15, 2012, at 8:26 AM, tom cook wrote:
>>>
>>> HI,
>>>> I just received this email from a developer interested in using our
>>>> WMS feeds, but getting errors. I really don't know much about WMS, and
>>>> just enabled it the typical TDS manner. He has provided a copy of the
>>>> crossdomain.xml file that apparently is the root of his errors. Does
>>>> anyone know more about this? Can I just put the crossdomain.xml file
>>>> some where in the TDS path to resolve this?
>>>> Thanks,
>>>> Tom
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Frank Roberts <froberts@xxxxxxxxxxxxxxxx>
>>>> Date: Tue, Aug 14, 2012 at 12:45 PM
>>>> Subject: WFS connection to 6km data
>>>> To: jimp@xxxxxxxx, tmcook@xxxxxxxx
>>>> Cc: Bill Robberson
>>>> <Robberson.Bill@xxxxxxxxxxx.**gov<Robberson.Bill@xxxxxxxxxxxxxxx>>,
>>>> Cheryl Henley
>>>> <henley.cheryl@xxxxxxx>
>>>>
>>>>
>>>> My name is Frank Roberts and I am working with Bill Robberson at US
>>>> EPA in San Francisco to make use of your WFS connection to 6km data
>>>> found at the following location:
>>>>
>>>>
>>>>
>>>> http://hfrnet.ucsd.edu/**thredds/wms/HFRNet/USWC/6km/**
>>>> hourly/RTV?VERSION=1.3.0&**REQUEST=GetCapabilities&**SERVICE=WMS<http://hfrnet.ucsd.edu/thredds/wms/HFRNet/USWC/6km/hourly/RTV?VERSION=1.3.0&REQUEST=GetCapabilities&SERVICE=WMS>
>>>>
>>>>
>>>>
>>>> In working with the above service, I seem to be getting an error. It
>>>> appears that the server may be missing a file at the root of the web
>>>> service:
>>>>
>>>> http://hfrnet.ucsd.edu/**crossdomain.xml<http://hfrnet.ucsd.edu/crossdomain.xml>
>>>>
>>>>
>>>>
>>>> The crossdomain.xml file is used by some software such as Adobe Flash
>>>> when combing services and it is required for the mash up of services
>>>> to work correctly. I imagine I might be the first person that may
>>>> have run into this issue. The following is a quick right up of what
>>>> the crossdomain.xml file does:
>>>>
>>>> http://www.adobe.com/devnet/**articles/crossdomain_policy_**
>>>> file_spec.html<http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html>
>>>>
>>>>
>>>>
>>>> Can I get someone to verify the existence of the crossdomain.xml file
>>>> on the server? In the event that it is missing, I would gladly
>>>> provide you a copy of one I already have in existence. In fact, I
>>>> will attach it to this email, if that is of any help.
>>>>
>>>>
>>>>
>>>> I know utilization of your service is very important to the EPA, and I
>>>> would like to do whatever I can to get access.
>>>>
>>>>
>>>>
>>>> Thanks for your assistance,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Frank Roberts
>>>>
>>>> Geo Developer
>>>>
>>>> Phone: (208)699-2712
>>>>
>>>> Innovate! Inc.
>>>> <crossdomain.xml>_____________**______________________________**____
>>>> thredds mailing list
>>>> thredds@xxxxxxxxxxxxxxxx
>>>> For list information or to unsubscribe, visit:
>>>> http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/>
>>>>
>>> **********************
>>> "The contents of this message do not reflect any position of the U.S.
>>> Government or NOAA."
>>> **********************
>>> Roy Mendelssohn
>>> Supervisory Operations Research Analyst
>>> NOAA/NMFS
>>> Environmental Research Division
>>> Southwest Fisheries Science Center
>>> 1352 Lighthouse Avenue
>>> Pacific Grove, CA 93950-2097
>>>
>>> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
>>> voice: (831)-648-9029
>>> fax: (831)-648-8440
>>> www: http://www.pfeg.noaa.gov/
>>>
>>> "Old age and treachery will overcome youth and skill."
>>> "From those who have been given much, much will be expected"
>>> "the arc of the moral universe is long, but it bends toward justice"
>>> -MLK Jr.
>>>
>>> ______________________________**_________________
>>> thredds mailing list
>>> thredds@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/>
>>>
>>
>>
>> Jay,
>
> We're a little unclear on exactly what's going on here. It seems that one
> server (host A - ucsd in this case) is being asked by another server (host
> B ) to serve up some data. If B puts in a request to A, why does A need to
> specifically authorize the request? What are the security implications
> here, since that seems to be the underlying rationale? If security is the
> issue, then is seems perhaps unwise to set domain="*" in the <allow-access>
> tag.
>
> Thanks for your comments.
>
> -Lansing
>
>
> ______________________________**_________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/>
>
