On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry <[email protected]> wrote:
Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
One proposed way of doing this would be a single header, of the form:
x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
allow=*.opera.com,example.net;
This incorporates the idea from the IE team, and extends on it.
Have you taken a look at ABE?
http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf
I am not quite certain what you are referring to, the document is a
ruleset for how to express what is allowed and disallowed. Do you mean
that clients should be using a URL list, or that servers should be
using this particular grammar to decide which headers to send with
their URLs?
For a domain wide policy file a document like this might work well
though.
ABE is meant to be configured in 3 ways:
1. With user-provided rules, deployed directly client-side
2. With community-provided rules, downloaded periodically from a
trusted repository
3. As a site-wide policy deployed on the server side in a single
file, much like crossdomain.xml
See http://hackademix.net/2008/12/20/introducing-abe/ and especially
this http://hackademix.net/2008/12/20/introducing-abe/#comment-10165
comment about site-provided rules and merging.
--
Giorgio
Sigbjørn Vik wrote, On 23/02/2009 11.42:
On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry <[email protected]> wrote:
Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
One proposed way of doing this would be a single header, of the form:
x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
allow=*.opera.com,example.net;
This incorporates the idea from the IE team, and extends on it.
Have you taken a look at ABE?
http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf
I am not quite certain what you are referring to, the document is a
ruleset for how to express what is allowed and disallowed. Do you mean
that clients should be using a URL list, or that servers should be
using this particular grammar to decide which headers to send with
their URLs?
For a domain wide policy file a document like this might work well
though.
For cross-domain resources, this means that a browser would first have
to make a request with GET and without authentication tokens to get the
x-cross-domain-options settings from the resource. If the settings
allow, a second request may be made, if the second request would be
different. The result of last request are handed over to the document.
Have you considered using OPTIONS for the pre-flight request, similar
to how Access Control for Cross-Site Requests does it?
http://www.w3.org/TR/access-control/#cross-site2
Good point. Trying to use OPTIONS for existing servers might break
them, a GET might be safer. Then again, OPTIONS shouldn't break
anything, GETs might have side-effects where OPTIONS don't, and an
OPTIONS reply typically has a much smaller payload than a GET reply.
In the case of a reply to a pre-flight request where the user agents
has cookies but the server replies that contents are the same with or
without cookies, an OPTIONS request would require two requests, a GET
only one. OPTIONS is probably more in the spirit of HTTP though.
Either could work, the idea is the same. Which would be better would
have to be researched empirically, but OPTIONS might be the better
candidate.
