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/
