[Mulgara-general] CORS headers

[Gregg Reynolds]

On Thu, Sep 10, 2009 at 8:09 AM, Paul Gearon <gearon at ieee.org> wrote:

> On Thu, Sep 10, 2009 at 8:31 AM, Gregg Reynolds <dev at mobileink.com> wrote:
> > Once I've done a little more experimenting with configurations I'll
> submit a
> > patch, but in the meantime, in case anybody is interested, here's what
> you
> > need to do to set the Access-Control-Allow-Origin header, per the CORS
> > spec.  In
> > src/jar/querylang/java/org/mulgara/protocol/http/ProtocolServlet.java
> stick
> > something like the following in doGet:
> >
> >       String CORS_Origin = req.getHeader("Origin");
> >       if (CORS_Origin.startsWith("http://localhost") ||
> > CORS_Origin.startsWith("null")) {
> >       resp.setHeader("Access-Control-Allow-Origin", CORS_Origin);
> >       }
>
> "localhost" isn't really appropriate here, as there are lots of ways
> to talk to the current server.
>
> The two things I can think of are to check the session, or else to go
> through our list of server aliases. The list of aliases makes me
> uncomfortable for some reason (lack of authority in this list), though
> it's probably OK. The session is worse, since cookies may be off, or a
> browser could go off to another site which then tries to go back to
> the Mulgara server.



>

I'm not very familiar with the session stuff, but it looks to me like the
idea is to always go by the Origin header of the request.  The requesting
User Agent is expecting that.

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.

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<http://java.sun.com/products/servlet/Filters.html>.
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<http://jetty.mortbay.org/apidocs/org/mortbay/xml/XmlConfiguration.html>from
within CORS.java to obtain the <origin, allow?> pairs and populate a
lookup table in CORS.java; see this
example.<http://jetty.mortbay.org/jetty/jetty-6/xref/org/mortbay/jetty/example/FromXmlConfiguration.html>
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?

-gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-general/attachments/20090910/75129273/attachment.htm>