Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
We had a similar discussion a few months back due to a request from a 3rd party developer who wanted to use Flash with our TDS. It used the crossdomain.xml, which the differences are explained in the code.google.com link Dennis sent. There was a similar concern about the analog to the "access-control-allow-origin: *" setting. I've been running our server with it, and haven't noticed anything out of the ordinary. I do explicitly block IP addresses from certain regions with tomcat already, but haven't seen any nefarious activity. (Of course now that I said it aloud, I will be slammed by rogue requests and DoS attacks). On Wed, Apr 24, 2013 at 2:37 PM, Dennis Heimbigner <dmh@xxxxxxxxxxxxxxxx> wrote: > There are some things that worry me. > > 1. From http://en.wikipedia.org/wiki/Cross-origin_resource_sharing: >> To allow access from all domains, a server can send the following >> response header: >> Access-Control-Allow-Origin: * >> However, this might not be appropriate for situations in >> which security is a concern. > > 2. This page: > https://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity > illustrates a number of security issues. > > 3. from https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS >> Important note: when responding to a credentialed request, >> server must specify a domain, and cannot use wild carding. >> The above example would fail if the header was wildcarded as: >> Access-Control-Allow-Origin: *. > > I think this needs a lot more thinking out. > > =Dennis Heimbigner > Unidata > > > > Jon Blower wrote: >> Hi all, >> >> Regarding the CORS issue - as far as I know, Roberto is right and there is >> no issue for the server in enabling this. I considered the same question >> for our ncWMS server software, although I haven't looked into it in detail. >> My tentative conclusion is that this is a matter for deployers not >> developers. CORS can be enabled using a servlet filter that is installed >> separately from THREDDS (e.g. [1]), so data providers can make a decision >> whether or not to enable this, and software providers don't have to make the >> decision for them. >> >> Just my thoughts. It would of course be possible to bundle such a filter >> with THREDDS but if so, my inclination would be to turn it off by default >> and publish a document about the implications of turning it on (i.e. a >> document written by someone who knows more about this than I do!) >> >> Cheers, >> Jon >> >> [1] http://software.dzhuvinov.com/cors-filter-installation.html >> >> _______________________________________________ >> thredds mailing list >> thredds@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ > > _______________________________________________ > thredds mailing list > thredds@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
thredds archives: