Re: [thredds] crossdomain.xml

Whenever a Flash application tries to access a web service, the Flash Player 
will try to load a crossdomain.xml file at the root of that host. As Mike 
mentioned, that is the time and place where the server administrator can 
allow/disallow/restrict access to their services from flash applications.

As to the question of if domain="*" is advisable or not, I think the answer is 
it depends. Let's look at the case of a ESRI WMS server. Here is their 
crossdomain.xml

http://server.arcgisonline.com/crossdomain.xml

<cross-domain-policy>
<allow-access-from domain="*" secure="false"/>
<site-control permitted-cross-domain-policies="all"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

This server provides access to a lot of WMS services, and they want to allow 
all hosts (and potential clients) access via Flash/Flex applications. In my 
case, only my Flex applications within my domain are allowed access to my 
Thredds WMS service. Maybe someday another developer will come along and will 
want to create a Flash/Flex application that uses my TDS WMS maps. That hasn't 
happened yet, so I'm being restrictive in the meantime. In my mind, the 
crossdomain.xml files don't provide any additional real security, because 
someone could still access my WMS maps via JavaScript, Java, Perl or any other 
number of non-Flash languages. I liked Mike's phrase of 'Flash 
self-enforcement'.


On Aug 15, 2012, at 9:45 AM, Roy Mendelssohn wrote:

> 
> On Aug 15, 2012, at 9:38 AM, Lansing Madry wrote:
> 
>> 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
> 
> Even more so, Jay claims the file is need to enforce security,  By default, 
> in Javascript, crossdomain requests are not allowed.  So this in fact opens 
> things up, not clamp things down.  \ncWMS works on this site, at least in my 
> tests.  So they would be opening up a crossdomain request so that someone 
> outside could use Flex?????
> 
> My guess is that it is fact the Oregon State folks who are making the cross 
> domain request, and they are the ones who need to have the crossdomain file.  
> This is a guess,  I could be wrong, but it would make more sense.
> 
> -Roy
> 
> 
> **********************
> "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/ 

Jay Alder
US Geological Survey
Oregon State University
104 COAS Admin Building
Office Burt Hall 166
http://blogs.oregonstate.edu/alderj/



  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: