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
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
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@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
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
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
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/
**********************
"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,
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
