[Mulgara-general] CORS headers

[Paul Gearon]

On Thu, Sep 10, 2009 at 11:45 AM, Gregg Reynolds <dev at mobileink.com> wrote:
>
> On Thu, Sep 10, 2009 at 8:09 AM, Paul Gearon <gearon at ieee.org> wrote:
>> The latter makes me wonder.... does this sort of configuration allow
>> for an AJAX application from some third party to run queries against
>> the data store? This is an important use case.
>
> To tell you the truth I haven't mastered the CORS stuff yet; I don't even
> know how cross-site attacks work, but I'm willing to take the W3C's word
> that it's a security problem so CORS is a Good Thing.  In any case, there it
> is, in FF 3.5, so cross-site queries in FF3.5 won't work unless the servers
> are properly configured.  So I think the answer to your question is, yes,
> CORS is intended to allow safe cross-site scripting, which is pretty
> essential for web apps these days.  The Semantic Web would have a pretty
> hard row to hoe without it.

This is understandable for a "web server", but Mulgara is a database
that happens to provide an HTTP interface. While I'm certain there
will be security issues, I can't see how it will be comparable.

> As I understand it, what happens is the User Agent submits a request from a
> webpage, originating at server X, to server Y, and informs server Y of this
> fact using the "Origin" header.  Server Y then decides if that's ok; if it
> is, its response includes the "Access-Control-Allow-Origin" header
> (hereinafter (ACAO header), with the same value as the Origin of the
> request.  Then the UA can see that all is hunky-dory and pass on the full
> response to the client code.  So the logic must be driven by the request
> headers.  I have no idea how that is supposed to protect us from malicious
> web stuff, but there it is.
>
> So the webmaster is going to have to configure the server appropriately for
> any resources that might be requested via XMLHttpRequest (Ajax).  I haven't
> worked through exactly how one might best do that, and probably won't, since
> I'm not really a webmaster, but the obvious easy way, at least for
> publicly-available data, is to set a global option to always honor the
> Origin header and respond with the appropriate ACAO header.
>
> For Mulgara's default server config, I suggest that this be supported via a
> CORS.java filter setup via a configuration file.  I think (though I'm not
> certain) the way to do this is implement it as a filter.  The XML config
> file would have some kind of element representing "Origin" values, with a
> boolean to indicate Allow/NoAllow.  If I understand theJetty config idea,
> one would then  use org.mortbay.xml.XmlConfiguration from within CORS.java
> to obtain the <origin, allow?> pairs and populate a lookup table in
> CORS.java; see this example.  Then at runtime it uses the table to set the
> ACAO header.  That way the admin can change the CORS response via config
> file, without recompiling.  Does that make any sense?

I suppose it would be useful if you're setting up your server for your
own exclusive use, in which case a configurable filter would be good.
But for public access then you'd be saying that you want to accept
everything all the time, meaning that you'd want this filter disabled.

Paul