<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote type="cite">On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry
<a class="moz-txt-link-rfc2396E" href="mailto:bil@corry.biz"><bil@corry.biz></a> wrote:
<br>
<br>
<blockquote type="cite">Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
<br>
<blockquote type="cite">One proposed way of doing this would be a
single header, of the form:
<br>
x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
<br>
allow=*.opera.com,example.net;
<br>
This incorporates the idea from the IE team, and extends on it.
<br>
</blockquote>
<br>
Have you taken a look at ABE?
<br>
<br>
<a class="moz-txt-link-freetext" href="http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf">http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf</a>
<br>
</blockquote>
<br>
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?
<br>
For a domain wide policy file a document like this might work well
though.
</blockquote>
ABE is meant to be configured in 3 ways:<br>
<ol>
<li>With user-provided rules, deployed directly client-side</li>
<li>With community-provided rules, downloaded periodically from a
trusted repository<br>
</li>
<li>As a site-wide policy deployed on the server side in a single
file, much like crossdomain.xml</li>
</ol>
See <a class="moz-txt-link-freetext" href="http://hackademix.net/2008/12/20/introducing-abe/">http://hackademix.net/2008/12/20/introducing-abe/</a> and especially
this <a class="moz-txt-link-freetext" href="http://hackademix.net/2008/12/20/introducing-abe/#comment-10165">http://hackademix.net/2008/12/20/introducing-abe/#comment-10165</a>
comment about site-provided rules and merging.<br>
--<br>
Giorgio<br>
<br>
Sigbjørn Vik wrote, On 23/02/2009 11.42:
<blockquote cite="mid:op.upsv0srx41y844@id-c0735.oslo.opera.com"
type="cite">On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry
<a class="moz-txt-link-rfc2396E" href="mailto:bil@corry.biz"><bil@corry.biz></a> wrote:
<br>
<br>
<blockquote type="cite">Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
<br>
<blockquote type="cite">One proposed way of doing this would be a
single header, of the form:
<br>
x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
<br>
allow=*.opera.com,example.net;
<br>
This incorporates the idea from the IE team, and extends on it.
<br>
</blockquote>
<br>
Have you taken a look at ABE?
<br>
<br>
<a class="moz-txt-link-freetext" href="http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf">http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf</a>
<br>
</blockquote>
<br>
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?
<br>
For a domain wide policy file a document like this might work well
though.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">For cross-domain resources, this means that
a browser would first have
<br>
to make a request with GET and without authentication tokens to get the
<br>
x-cross-domain-options settings from the resource. If the settings
<br>
allow, a second request may be made, if the second request would be
<br>
different. The result of last request are handed over to the document.
<br>
</blockquote>
<br>
Have you considered using OPTIONS for the pre-flight request, similar
to how Access Control for Cross-Site Requests does it?
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/access-control/#cross-site2">http://www.w3.org/TR/access-control/#cross-site2</a>
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
</body>
</html>