Requirements
 
Prerequisite knowledge
This article assumes that you have basic knowledge of using the Adobe Media Server and know how to run a Flash based SWF client.
 
Required products

 

User level
Intermediate
 
This article provides an overview on the cross-domain policy file and how you can configure it for HTTP Streaming in Adobe Media Server.
 
Why do you require a crossdomain.xml file?
 
A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains. When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction.
 
To allow a Flash media player hosted on another web server to access content from the Adobe Media Server web server, we require a crossdomain.xml file. A typical use case will be HTTP streaming (VOD or Live) to a Flash Player. The crossdomain.xml file grants a web client the required permission to handle data across multiple domains.
 
Element Specification
 
The crossdomain.xml file may contain the following elements:
 
cross-domain-policy
 
The cross-domain-policy element is the root element for cross-domain policy files. It is a container for policy file definitions and has no attributes of its own.
 
Feature
Details
Child of
None; cross-domain-policy is the root node
Child elements
  • site-control
  • allow-access-from
  • allow-access-from-identity
  • allow-http-request-headers-from

Attributes (none)

 

site-control
 
The site-control element defines the meta-policy for the current domain. A meta-policy specifies acceptable domain policy files other than the master policy file located in the target domain's root and named crossdomain.xml.
If a client is instructed to use a policy file other than that of the master policy file, the client must first check the master policy’s meta-policy to determine if the requested policy file is allowed.
 
Feature
Details
Child of
cross-domain-policy
Child elements
None

 

Attributes

 

Attribute
Details
permitted-cross-domain-policies
Specifies the meta-policy. The default value is master-only for all policy files except socket policy files, where the default is all. Allowed values are:
  • none: No policy files are allowed anywhere on the target server, including this master policy file.
  • master-only: Only this master policy file is allowed.
  • by-content-type: [HTTP/HTTPS only] Only policy files served with Content-Type: text/x-cross-domain-policy are allowed.
  • by-ftp-filename: [FTP only] Only policy files whose file names are crossdomain.xml (i.e. URLs ending in /crossdomain.xml) are allowed.
  • all: All policy files on this target domain are allowed.

 

allow-access-from
 
The allow-access-from element grants a requesting domain to read data from the target domain. For each request that is given permission, a new allow-access-from element is required, although multiple domains can be given access with one allow-access-from element by using a wildcard (*).
 
Feature
Details
Child of
cross-domain-policy
Child elements
None

 

Attributes
 
Attribute
Details
domain
Specifies a requesting domain to be granted access. Both named domains and IP addresses are acceptable values. Subdomains are considered different domains. A wildcard (*) can be used to match all domains when used alone, or multiple domains (subdomains) when used as a prefix for an explicit, second-level domain name separated with a dot (.). Specific, individual domains require separate allow-access-from elements.
To grant access to the requesting documents that have no associated domain, such as local files, a "*" wildcard must be specified for the domain attribute. This has the effect of allowing access by any requesting document from any origin. However, granting access to documents having no domain associated is not recommended, and you should only grant access to "*" if you are certain that the scope of the policy file does not host any access-controlled, personalized, or private data.
to-ports
[Sockets only] A comma-separated list of ports or range of ports that a socket connection is allowed to connect to. A range of ports is specified through a dash (-) between two port numbers. Ranges can be used with individual ports when separated with a comma. A single wildcard (*) can be used to allow all ports.
secure
[HTTPS and Sockets only, optional] Specifies whether access is granted only to HTTPS documents from the specified origin (true) or to all the documents from the specified origin (false).
If secure is not specified in an HTTPS policy file, it defaults to true. Using false in an HTTPS policy file is not recommended because this compromises the security offered by HTTPS.
In socket policy files, the default is false. It is only useful to specify secure=”true” when the socket server is accepting connections from the local host since local socket connections are generally not at risk of the man-in-the-middle attacks that could alter the secure=”true” declaration.

 

allow-access-from-identity
 
The allow-access-from-identity element grants permissions based on cryptographic credentials, unlike allow-access-from the grants permissions based on origin. The only mechanism defined so far is to allow access by any document that has been digitally signed by a given party, where the party is identified by a certificate.
 
Feature
Details
Child of
cross-domain-policy
Child elements
Signatory: Identifies the signing party. Only one such element is allowed per allow-access-from-identity element.

 

Signatory

One signatory element is used to contain the certificate element.
 
Feature
Details
Child of
allow-access-from-identity
Child elements
certificate: Identifies the signing party's certificate. Only one such element is allowed per signatory element.

 

certificate

One signatory element is used to contain the certificate element.
 
Feature
Details
Child of
Signatory
Child elements
None

 

Attributes
 
A certificate element must contain two attributes:
 
Attribute
Details
fingerprint-algorithm
The hash algorithm used to compute the certificate fingerprint. The attribute value is case-insensitive. The only hash algorithm name defined at present is sha-1, but others are expected to be defined as implementations require.
fingerprint
The fingerprint of the signing certificate, expressed as a string of hexadecimal digits. The attribute value is case-insensitive, and may contain spaces or colons, which are ignored. In the case of a sha-1 hash-algorithm, fingerprint must contain 40 hexadecimal digits

 

Note: allow-access-from-identity elements are not supported by Flash Player.
 
allow-http-request-headers-from
 
The allow-http-request-headers-from element grants a requesting document from a requesting domain to send the user-defined headers to the target domain. Whereas the allow-access-from element grants permission to pull data from the target domain. This tag grants permission to push data in the form of headers.
 
Feature
Details
Child of
cross-domain-policy
Child elements
None

 

Attributes

 

Attribute
Details
domain
Specifies the domain that is to be granted access. Both named domains and IP addresses are acceptable values. Subdomains are considered as different domains. A wildcard (*) can be used to match all domains when used alone, or multiple domains (subdomains) when used as a prefix for an explicit, second-level domain name separated with a dot (.). Individual domains require separate allow-access-from elements.
headers
A comma-separated list of headers that the allowed requesting domain is permitted to send. A wildcard character (*) can be used to allow all headers or for header suffixes, allowing for headers that start with the same characters but end with different characters.
secure
[HTTPS only, optional] When false, allows an HTTPS policy file to grant access to a request coming from an HTTP source. The default is true, providing only HTTPS source permission. Using false is not recommended.
 
Matching rules
 
The following rules are used in determining if a value in the domain attribute of the allow-access-from or allow-http-request-headers-from elements matches an actual domain name:
 
  • Individual named domains or subdomains must match exactly.
  • Explicit IP addresses do not match named domains, even if they refer to the same host.
  • Domain wildcards, such as *.example.com, match both the domain alone and any subdomains.
  • An overall wildcard, (*) allows access by all requestors and is not recommended. allow-all permissions should only be used when all content in the policy file's scope is completely public.

 

Domain value
will match...
will not match...
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
Any https domains
127.0.0.1
http://127.0.0.1
http://localhost
http://127.0.0
http://127.0.0.2
www.example.*
No matches, invalid domain
None
 
Master Policy File
 
Policy files grant read access to data, permit a client to include custom headers in cross-domain requests, and grant permissions for socket-based connections. The most common location for a policy file on a server is in the root directory of a target domain with the filename crossdomain.xml (e.g. http://example.com/crossdomain.xml) — the default location that clients check when a policy file is required. Policy files hosted this way are known as master policy files.
 
Examples of crossdomain.xml file
 
Example 1: allow-access-from: Allowing access to root domains

 

<?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>

 

The site-control element here specifies that only this master policy file should be considered valid on this domain. The allow-access-from element specifies that content from the example.com requesting domain can access any data within the target domain (the domain in which this policy file has been saved). Finally, the allow-http-request-headers-from element indicates that a SOAPAction header is also allowed to be sent with requests made to the target domain from adobe.com
 
Example 2: cross-domain-policy: Least permissive 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>

 

This is the least permissive master policy file definition. It restricts any policy file, including this one, from granting permissions of any type to any requesting domain.
 
Example 3: cross-domain-policy: Least restrictive 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>

 

This is the most permissive master policy file definition (not recommended). It allows any policy file on the target domain to grant permissions, allows access to any of its file, and permits any header to be sent to the server, all of these are possible even through HTTPS despite the source being HTTP.
 
Setting crossdomain.xml file for HTTP Streaming in Adobe Media Server
 
To allow a Flash media player hosted on another web server to access content from the Adobe Media Server, you require a crossdomain.xml file. A typical use case will be to perform HTTP streaming (VOD or Live) to a Flash Player. The crossdomain.xml file grants a web client the required permission to handle data across multiple domains.
 
Configuring the crossdomain.xml
 
  1. In a text-editor create a cross-domain policy file by providing the appropriate value for the tags (See above).
A simple crossdomain.xml would look like this:
 
<?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>
 
(This is not recommended as it allows connection from all domains and allows all policies)
Name the file crossdomain.xml and save.
 
  1. Copy the crossdomain.xml under the Apache Document root. By default it is root_install/webroot.
You can verify the Apache webroot by opening the httpd.conf file under root_install/Apache2.2/conf folder. In httpd.conf search for “DocumentRoot”. The value for this tag specifies the Apache document root.
 
  1. Restart Adobe Media Server
 
Troubleshooting Issues
 
Error #2032 on the client
 
An error #2032 on the client generally means that the crossdomain.xml was not found.  You can verify this by checking Apache error logs present under root_install/Apache2.2/logs. You’ll find the error “File does not exist”

 

Solution: Place a crossdomain.xml under the Document root of Apache
(See configuring the crossdomain.xml section)

 

Crossdomain.xml is present, but an Error 404 is thrown for crossdomain requests
 
Check if the crossdomain.xml file is present in the correct path. You can verify this by checking Apache error logs present under root_install/Apache2.2/logs. You’ll find the error “File does not exist” with the path where Apache is looking for the crossdomain.xml file.

 

Where to go from here
 
The crossdomain.xml file grants a web client permission to handle data across multiple domains. When streaming content via HTTP, we require a crossdomain.xml file to allow a Flash media player hosted on another web server to access content from the Adobe Media Server web server.

 

Learn more about cross-domain file specification here.