![]() ![]() ![]() | |
![]() | |
![]() | |
![]() |
A Flash document can load data from an external source by using one of the following data loading calls: XML.load()
, XML.sendAndLoad()
, LoadVars.load()
, LoadVars.sendAndLoad()
, loadVariables()
, loadVariablesNum()
. Also, a SWF file can import runtime shared libraries, or assets defined in another SWF file, at runtime. By default, the data or SWF media, in the case of runtime shared libraries, must reside in the same domain as the SWF that is loading that external data or media.
To make data and assets in runtime shared libraries available to SWF files in different domains, use a cross-domain policy file. A cross-domain policy file is an XML file that provides a way for the server to indicate that its data and documents are available to SWF files served from certain domains, or from all domains. Any SWF file that is served from a domain specified by the server's policy file will be permitted to access data or assets from that server.
When a Flash document attempts to access data from another domain, Flash Player automatically attempts to load a policy file from that domain. If the domain of the Flash document that is attempting to access the data is included in the policy file, the data is automatically accessible.
Policy files must be named crossdomain.xml and reside at the root directory of the server that is serving the data. Policy files function only on servers that communicate over HTTP, HTTPS, or FTP. The policy file is specific to the port and protocol of the server where it resides.
For example, a policy file located at https://www.macromedia.com:8080/crossdomain.xml will apply only to data loading calls made to www.macromedia.com over HTTPS at port 8080.
An exception to this rule is the use of an XMLSocket object to connect to a socket server in another domain. In that case, an HTTP server running on port 80 in the same domain as the socket server must provide the policy file for the method call.
An XML policy file contains a single <cross-domain-policy>
tag, which in turn contains zero or more <allow-access-from>
tags. Each <allow-access-from>
tag contains one attribute, domain
, which specifies either an exact IP address, an exact domain, or a wildcard domain (any domain). Wildcard domains are indicated by either a single asterisk (*
), which matches all domains and all IP addresses, or an asterisk followed by a suffix, which matches only those domains that end with the specified suffix. Suffixes must begin with a dot. However, wildcard domains with suffixes can match domains that consist of only the suffix without the leading dot. For example, foo.com is considered to be part of *.foo.com. Wildcards are not allowed in IP domain specifications.
If you specify an IP address, access will be granted only to SWF files loaded from that IP address using IP syntax (for example, http://65.57.83.12/flashmovie.swf), not those loaded using domain-name syntax. Flash Player does not perform DNS resolution.
Here is an example policy file that permits access to Flash documents that originate from foo.com, friendOfFoo.com, *.foo.com, and 105.216.0.40, from a Flash document on foo.com:
<?xml version="1.0"?> <!-- http://www.foo.com/crossdomain.xml --> <cross-domain-policy> <allow-access-from domain="www.friendOfFoo.com" /> <allow-access-from domain="*.foo.com" /> <allow-access-from domain="105.216.0.40" /> </cross-domain-policy>
A policy file that contains no <allow-access-from>
tags has the same effect as not having a policy on a server.
![]() | |
![]() | |
![]() | |
![]() ![]() ![]() |