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/
