Note that it is particularly important, but we did what Rob requested a
year or two ago, opening http://iridl.ldeo.columbia.edu/ to cross-browser
access. My understanding is that it means that a browser can use
javascript from one site to access data on our site -- it does not change
the security of the data, which is still dependent on the browser. Other
sites running our software will have the headers set as well. The example
that Dennis sent seems to be about using the Origin header to restrict
access -- that is not real security, there must be lots of exploits around
that. I would like to better understand cookie-leakage, but a apriori
cookies are supposed to be confined to the domain that set them.
On Wed, Apr 24, 2013 at 10:11 PM, Tom Kunicki <tkunicki@xxxxxxxx> wrote:
>
> Hi Rob,
>
> The project uses a maven war overlay, With this, wars listed as
> dependencies are exploded and the contents of the project injected and then
> the war file is recreated. This project lists a jar file with a CORS
> filter implementation and then uses an XSLT to merge the contents of the
> web.xml files needed to configure thredds and the CORS filter. So it's
> just a project that injects things into the thredds war. We use this
> technique to customize and version control our thredds deployments (inject
> IOSPs, ncSOS, etc...). The CORS filter configuration is in
> src/main/webapps/WEB-INF/web.xml
>
> I guess the point in putting up this project is to show how quickly it
> could be done if needed. As Jon mentioned earlier you can also enable CORS
> for an entire servlet container.
>
> CORS support doesn't require any development on Unidata's side. I don't
> think it's desirable for the behavior to be on by default, this is
> something that the user deploying thredds should be enabling explicitly if
> desired.
>
> Tom
>
> On Apr 24, 2013, at 6:29 PM, Roberto De Almeida <roberto@xxxxxxxxxxxxx>
> wrote:
>
> > That was fast, Tom! How does this work, does it add an option for
> turning on CORS on THREDDS?
> >
> > As I was saying to Dennis, what I'm suggesting here is: Javascript is
> becoming a major player as a programming language, and if we want our data
> to be widely accessed and consumed by the new generation of applications in
> ways that we cannot anticipate, we should add these headers. If security is
> important we can explain to users how to configure authentication, how to
> setup SSL certificates, and how to turn off CORS (or restrict the hosts
> instead of using a wildcard).
> >
> > I think this should be on by default (like I did in Pydap) because
> otherwise no one will turn it on, and all the data currently available via
> OPeNDAP will be inaccessible to Javascript, because this is not a policy
> that can be changed on the browser. But if we start doing it now, providers
> will eventually upgrade their servers, and maybe next year we'll have WebGL
> applications that can display data from any DAP server on the browser in
> 3D, and analyse it using asm.js.
> >
> > --Rob
> >
> > On Wed, Apr 24, 2013 at 12:52 PM, Tom Kunicki <tkunicki@xxxxxxxx> wrote:
> >
> > I've created a maven project to create a CORS enable thredds war:
> >
> > https://github.com/tkunicki-usgs/thredds-cors
> >
> > CORS is useful for working around single origin issues in browser apps.
> A CORS enabled server essentially tells the browser that it's ok to let
> code loaded from a different server utilize resources from the CORS enabled
> server.
> >
> > Tom Kunicki
> > Center for Integrated Data Analytics
> > U.S. Geological Survey
> > 8505 Research Way
> > Middleton, WI 53562
> >
> >
> >
> > On Apr 24, 2013, at 2:11 PM, Dennis Heimbigner <dmh@xxxxxxxxxxxxxxxx>
> wrote:
> >
> >> Perhaps more concretely, the thredds server
> >> currently supports access controls such as
> >> passwords and client-side keys. How would
> >> CORS affect those?
> >>
> >> =Dennis Heimbigner
> >> Unidata
> >>
> >> Roberto De Almeida wrote:
> >>> Hi, guys!
> >>> In 2006 I wrote an implementation of an OPeNDAP client in Javascript
> called
> >>> jsdap (https://code.google.com/p/jsdap/). At the time Javascript was
> still
> >>> a toy language and the XML HTTP Request (XHR) was unable of handling
> binary
> >>> data, but I managed to hack a full client that worked in all major
> browsers
> >>> (including IE by injecting vbscript!). And while it was written more
> as a
> >>> proof-of-concept the client is actually used in some data portals like
> >>> http://www.ifremer.fr/oceanotronPortal/. (A Node.js OPeNDAP server
> was also
> >>> added 3 years ago.)
> >>> Fast forward 7 years and we now have a lot of new technologies on the
> >>> table: a new XHR object with support for binary transfers, typed
> arrays and
> >>> WebGL. I've been playing again with using Javascript as an OPeNDAP
> client,
> >>> in particular to display real time information from OPeNDAP servers. I
> have
> >>> set up a small OPeNDAP server on one of my VPS streaming the system
> load
> >>> information:
> >>> http://vps.dealmeida.net:5000/.dds
> >>> http://vps.dealmeida.net:5000/.das
> >>> This is an infinite dataset (try "curl
> http://vps.dealmeida.net:5000/.asc";),
> >>> and it will keep streaming the data at one record per second until the
> >>> connection is broken. Keep in mind that this is a regular OPeNDAP
> Sequence,
> >>> and nothing was changed in the specification to make this work.
> >>> Nevertheless, I'm not aware of OPeNDAP clients that can access the
> stream
> >>> other than the development version of Pydap.
> >>> On another machine I have a widget displaying the information on a real
> >>> time graph: http://dealmeida.net/opendap-streaming/
> >>> You can see how everything was implemented on this Mercurial
> >>> repository<
> http://code.dealmeida.net/opendap-streaming/src/356dde80f6e55603c2ab7e581244015663504fda?at=demo
> >.
> >>> The
> >>> data is displayed by fetching the .dods response and parsing it. We
> still
> >>> need a few hacks to do this, but only because the data is being
> streamed
> >>> (Mozilla handles it nice; Chrome cannot stream binary data, so it still
> >>> fetches it as string). Handling regular OPeNDAP datasets should be
> pretty
> >>> straightforward with the new XHR, and I plan to rewrite jsdap as soon
> as I
> >>> have some free time.
> >>> *Now to my request:* the only reason that the demo works -- having a
> page
> >>> in one host displaying data from an OPeNDAP server on another -- is
> because
> >>> I enabled<
> http://code.dealmeida.net/pydap/commits/4c2d38b5822ba8f5f61e83bcb23230a2ca7e5da1
> >
> >>> CORS <http://en.wikipedia.org/wiki/Cross-origin_resource_sharing> on
> Pydap.
> >>> By default, now all DODS, DAS and DDS responses from Pydap have the
> >>> following additional headers:
> >>> Access-Control-Allow-Origin: *
> >>> Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type
> >>> These headers (the first one, actually) allow the responses to be
> accessed
> >>> through XHR from any host. As far as I know there is no downside in
> doing
> >>> this. Even if your server use cookies for authenticating access to
> certain
> >>> datasets the cookies *will not* be sent unless
> >>> the Access-Control-Allow-Credentials header is set (and set to true),
> which
> >>> would allow other sites to "steal" your data and download it by
> >>> impersonating a logged user.
> >>> My request is that all OPeNDAP servers enable CORS from any host by
> default
> >>> today, at least in the DODS, DAS and DDS responses; and if not by
> default,
> >>> at least as an option. This way, by the time Javascript matures enough
> so
> >>> that its performance on the browser becomes comparable to desktop
> >>> applications we can start building rich web applications that use all
> the
> >>> data available through OPeNDAP.
> >>> Some resources
> >>> About CORS: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing/
> >>> https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
> >>> Security concerns:
> >>>
> https://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
> >>> Thank you,
> >>> Rob
> >>
> >> _______________________________________________
> >> thredds mailing list
> >> thredds@xxxxxxxxxxxxxxxx
> >> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "pydap" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to pydap+unsubscribe@xxxxxxxxxxxxxxxx.
> > To post to this group, send email to pydap@xxxxxxxxxxxxxxxx.
> > Visit this group at http://groups.google.com/group/pydap?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> >
> >
> > --
> > Roberto De Almeida, PhD
> > http://dealmeida.net/
> > :wq
> > _______________________________________________
> > 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/
>
--
Dr. M. Benno Blumenthal benno@xxxxxxxxxxxxxxxx
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
