crossdomain.xml配置详解

本文概括介绍了跨域策略文件，以及如何在 Adobe Media Server 中为 HTTP 流式传输配置该文件。

为什么需要采用 crossdomain.xml 文件？

跨域策略文件 跨域策略文件是一种 XML 文档，旨在为 Web 客户端，比如 Adobe Flash Player 或 Adobe Acrobat（但不限于这两类客户端）授予跨域处理数据的权限。当客户端请求获取特定源域上托管的内容、且该内容将请求定向至除自身域以外的其他域时，远程域需要托管跨域策略文件，从而授予源域的访问权限，使客户端继续执行事务。

为了使另一台 Web 服务器上托管的 Flash Media Player 能够访问该 Adobe Media Server Web 服务器中的内容，我们需要使用 crossdomain.xml 文件。典型用例是将 HTTP 流（视频点播或直播）传输到 Flash Player。crossdomain.xml 文件可为 Web 客户端授予跨越多个域处理数据所需的权限。

元素规范

crossdomain.xml 文件可以包含以下元素：

cross-domain-policy

cross-domain-policy 元素是跨域策略文件的根元素。它是一种策略文件定义容器，没有自己的属性。

特性	详细信息
父元素	无；cross-domain-policy 是根节点
子元素	site-control allow-access-from allow-access-from-identity allow-http-request-headers-from

属性（无）

site-control

site-control 元素用于定义当前域的元策略。元策略则用于指定可接受的域策略文件，且该文件不同于目标域根元素（名为 crossdomain.xml）中的主策略文件。
如果客户端收到指示使用主策略文件以外的策略文件，则该客户端必须首先检查主策略的元策略，以确定请求的策略文件是否获得许可。

特性	详细信息
父元素	cross-domain-policy
子元素	无

属性

属性	详细信息
permitted-cross-domain-policies	指定元策略。除套接字策略文件外，所有策略文件的默认值均为 master-only，套接字策略文件的默认值为 all。允许的值包括： none: 目标服务器上的任何位置（包括这个主策略文件）均不允许使用策略文件。 master-only: 仅允许这个主策略文件。 by-content-type: [HTTP/HTTPS only] 仅允许 Content-Type:text/x-cross-domain-policy 提供的策略文件。 by-ftp-filename: [FTP only] 仅允许文件名为 crossdomain.xml（即以 /crossdomain.xml 结尾的 URL）的策略文件。 all: 允许此目标域中所有策略文件。

by-content-type仅允许 Content-Type:text/x-cross-domain-policy 提供的策略文件,访问下自己配置的

crossdomain.xml,使用f12查看content-type是否是，如果是application/xml则不能用by-content-type,

可以在tomcat或者jboss的ROOT.war的项目中web.xml设置

   <mime-mapping>

       <extension>xml</extension>

       <mime-type>text/x-cross-domain-policy</mime-type>

   </mime-mapping>

 

allow-access-from

allow-access-from allow-access-from 元素用于授权发出请求的域从目标域中读取数据。尽管通过使用通配符 (*)，一个 allow-access-from 元素可以为多个域授予访问权限，每个获得许可的请求都需要使用一个新的 allow-access-from元素。

特性	详细信息
父元素	cross-domain-policy
子元素	无

属性

属性	详细信息
domain	指定要授予访问权限的发出请求的域。命名域和 IP 地址值均为可接受的值。子域将被视作不同的域。通配符 (*) 单独使用时可用于表示所有域，在用作以句点 (.) 分隔的明确二级域名前缀时表示多个域（子域）。表示单个具体域时需要使用单独的 allow-access-from 元素 要授予不具备任何相关域的请求文档（如本地文件）的访问权限，必须在域属性中指定 "*" 通配符。这样即可允许访问任意来源的任意请求文档。不过，我们不建议授予没有任何相关域的文档的访问权限，只有确保策略文件不包含任何具有访问权限控制的个性化或私人数据时才能授予 "*" 访问权限。
to-ports	[Sockets only] 以逗号分隔的端口列表，或者允许连接到套接字连接的一系列端口。端口范围通过在两个端口号之间插入短划线 (-) 指定。端口范围在用逗号隔开时则可以用于指代单个端口。一个通配符 (*) 可用于表示允许所有端口。
secure	[HTTPS and Sockets only, optional] 指定仅授予指定来源的 HTTPS 文档的访问权限 (true)，还是授予指定来源的所有文档的访问权限 (false)。 如果 HTTPS 策略文件中未指定 secure，则默认为 true。不建议在 HTTPS 策略文件中使用 false，因为这会影响 HTTPS 的安全性。 在套接字策略文件中，默认值为 false。只有当套接字服务器接受本地主机连接时，指定 secure=”true” 才有意义，因为本地套接字连接通常不会面临中间人攻击的风险，因此无法更改 secure=”true” 声明。

allow-access-from-identity

allow-access-from-identity 元素根据加密凭据授予权限，而 allow-access-from 则截然不同，它根据来源授予权限。迄今为止，定义的唯一机制是允许访问由给定方（该方由证书指定）进行数字签名的所有文档。

特性	详细信息
父元素	cross-domain-policy
子元素	Signatory: 确定签名方。每个 allow-access-from-identity 元素仅允许具有一个此类元素。

Signatory
One signatory 使用一个 signatory 元素包含 certificate 元素。

特性	详细信息
父元素	allow-access-from-identity
子元素	certificate: 确定签名方证书。每个 signatory 元素仅允许具有一个此类元素。

certificate 
使用一个 signatory 元素包含 certificate 元素。

特性	详细信息
父元素	Signatory
子元素	无

属性

certificate 元素必须包含两个属性：

属性	详细信息
fingerprint-algorithm	这个哈希算法用于计算证书指纹。该属性值不区分大小写。目前定义的唯一哈希算法名称是 sha-1，但也可以根据实施需要定义其他算法名称。
fingerprint	签名证书的指纹，用十六进制字符串表示。该属性值不区分大小写，并且可以包含空格或冒号，但会遭到忽略。在 sha-1 哈希算法中，fingerprint 必须包含 40 个十六进制数字。

注意：Flash Player 不支持 allow-access-from-identity 元素。

allow-http-request-headers-from

allow-http-request-headers-from 元素用于授权发出请求的域中的请求文档将用户定义的标头发送到目标域。而 allow-access-from 元素旨在授权从目标域提取数据。这个标签授权以标头的形式推送数据。

特性	详细信息
父元素	cross-domain-policy
子元素	无

属性

属性	详细信息
domain	指定要授予访问权限的的域。命名域和 IP 地址值均为可接受的值。子域将被视作不同的域。通配符 (*) 单独使用时可用于表示所有域，在用作以句点 (.) 分隔的明确二级域名前缀时表示多个域。表示单个域时需要使用单独的 allow-access-from 元素。
headers	以逗号分隔的标头列表，表示允许发送的请求域。通配符 (*) 可用于准许所有标头或头后缀，从而支持以相同字符开头但以不同字符结尾的标头。
secure	[HTTPS only, optional] 如果设置为 false，则表示允许 HTTPS 策略文件授权访问 HTTP 源发出的请求。默认值为 true，表示仅提供 HTTPS 源权限。我们不推荐使用 false。

匹配规则

我们使用以下规则确定 allow-access-from 或 allow-http-request-headers-from 元素的域属性值是否与实际域名相符：

• 各个命名域或子域必须完全匹配。
• 显式 IP 地址与命名域不匹配，即使它们指代同一个主机也是如此。
• 域通配符（如 *.example.com）与该域本身及所有子域匹配。
• 整体通配符 (*) 允许所有请求者进行访问，但不推荐使用。只有在策略文件范围内的所有内容完全公开的情况下才应当使用 allow-all 权限。

域值	匹配项...	不匹配项...
www.example.com	http://www.example.com	http://example.com http://www.example.net http://www.adobe.com
*.example.com	http://example.com http://www.example.com http://deep.subdomain.example.com	http://www.example.net http://www.adobe.com
http://*.example.com	http://example.com http://www.example.com http://deep.subdomain.example.com	任何 https 域
127.0.0.1	http://127.0.0.1	http://localhost http://127.0.0 http://127.0.0.2
www.example.*	不匹配，无效域	无

主策略文件

策略文件用于授予数据读取权限，允许客户端在跨域请求中包含自定义标头，并授予基于套接字的连接权限。策略文件在服务器上的最常见位置是文件名为 crossdomain.xml (例如 http://example.com/crossdomain.xml) 的目标域根目录中——当客户端需要策略文件时的默认检查位置。以这种方式托管的策略文件称作主策略文件。

crossdomain.xml 文件示例

示例 1：allow-access-from：允许访问根域

 

<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="*.example.com"/> <allow-access-from domain="www.example.com"/> <allow-http-request-headers-from domain="*.adobe.com" headers="SOAPAction"/> </cross-domain-policy>

此处的site-control 元素用于指定该域仅将此主策略文件视为有效文件。allow-access-from 元素用于指定 example.com 请求域中的内容可以访问目标域（保存此策略文件的域）中的所有数据。最后，allow-http-request-headers-from 元素表示，通过从 adobe.com 向目标域发送请求还允许发送SOAPAction 标头。

示例 2：cross-domain-policy：最不宽松的策略

 

<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <site-control permitted-cross-domain-policies="none"/> </cross-domain-policy>

这是最不宽松的主策略文件定义。它可以限制任何策略文件（包括这个文件在内）向发出请求的任何域授予任何类型的权限。

示例 3：cross-domain-policy：受最少限制的策略

 

<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <site-control permitted-cross-domain-policies="all"/> <allow-access-from domain="*" secure="false"/> <allow-http-request-headers-from domain="*" headers="*" secure="false"/> </cross-domain-policy>

这是最宽松的主策略文件定义（不推荐使用）。它允许目标域上的任意策略文件授予权限，允许访问它的任何文件，并且允许向服务器发送任何标头，尽管源是 HTTP，即使通过 HTTPS 也可以执行所有操作。

在 Adobe Media Server 中设置 crossdomain.xml 文件实施 HTTP 流式传输

为了使另一台 Web 服务器上托管的 Flash Media Player 能够访问该 Adobe Media Server Web 服务器中的内容，我们需要使用 crossdomain.xml 文件。典型用例是将 HTTP 流（视频点播或直播）传输到 Flash Player。crossdomain.xml 文件可为 Web 客户端授予跨越多个域处理数据所需的权限。

配置 crossdomain.xml

1. 在 text-editor 中提供对应的标签值创建 cross-domain 策略文件（参见上文）。

一个简单的 crossdomain.xml 如下所示：

<?xml version="1.0"?> <!-- http://www.osmf.org/crossdomain.xml --> <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*" /> <site-control permitted-cross-domain-policies="all"/> </cross-domain-policy>

（不推荐使用此设置，因为它允许所有域连接并允许所有策略）
将该文件命名为 crossdomain.xml 并保存。

 

1. 复制 Apache Document 根目录下的 crossdomain.xml。默认情况下是指 root_install/webroot。

您可以打开 root_install/Apache2.2/conf 文件夹下的 httpd.conf 文件验证 Apache Webroot。在 httpd.conf 中，搜索 “DocumentRoot”。此标签的值用于指定 Apache Document 根目录。
Document 根目录是客户端查找 crossdomain.xml 的默认位置。

1. 重新启动 Adobe Media Server

疑难问题解答

客户端错误 #2032

客户端上出现错误 #2032 通常表示找不到 crossdomain.xml。您可以通过检查 root_install/Apache2.2/logs 下显示的 Apache 错误日志验证这项错误。您将会发现以下错误：“File does not exist（文件不存在）”

解决方案：将 crossdomain.xml 置于 Apache Document 根目录下。 （参见“配置 crossdomain.xml”部分）

Crossdomain.xml 存在，但系统针对 crossdomain 请求抛出错误 404

检查确认 crossdomain.xml 文件是否位于正确路径下。您可以通过检查 root_install/Apache2.2/logs 下显示的 Apache 错误日志验证这项错误。您将会在 Apache 查找 crossdomain.xml 文件的路径下发现错误：“File does not exist（文件不存在）”。

 

 转载自：设置 crossdomain.xml 文件实施 HTTP 流式传输

 

另：  flash跨域策略文件crossdomain.xml配置详解