Setting a crossdomain.xml file for HTTP streaming

This article provides an overview on the cross-domain policy file and how you can configure it for HTTP Streaming in Adobe Media Server.

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.

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.

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.

Attributes

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 (*).

Attributes

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.

Signatory
One signatory element is used to contain the certificate element.

certificate
One signatory element is used to contain the certificate element.

Attributes

A certificate element must contain two attributes:

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.

Attributes

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.

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.

Example 1: allow-access-from: Allowing access to root domains

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

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

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.

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:

(This is not recommended as it allows connection from all domains and allows all policies)
Name the file crossdomain.xml and save.

2. 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.
The Document root is the default location where the client will look for the crossdomain.xml

3. Restart Adobe Media Server

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.

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 .