To make data from a web server available to SWF files from other domains, you can create a cross-domain policy file
on your server. 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 is permitted to access data or assets from that server.
Cross-domain policy files affect access to a number of assets, including the following:
• Data in bitmaps, sounds, and videos
• Loading XML and text files
• Access to socket and XML socket connections
• Importing SWF files from other security domains into the security domain of the loading SWF file
Full details are provided in the rest of this chapter.
Policy file syntax
The following example shows a policy file that permits access to SWF files that originate from *.example.com,
www.friendOfExample.com and 192.0.34.166:
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="www.friendOfExample.com" />
<allow-access-from domain="192.0.34.166" />
</cross-domain-policy>
When a SWF file attempts to access data from another domain, Flash Player automatically attempts to load a policy
file from that domain. If the domain of the SWF file that is attempting to access the data is included in the policy file,
the data is automatically accessible.
By default, policy files must be named crossdomain.xml and must reside in the root directory of the server.
However, a SWF file can check for a different name or in a different directory location by calling the
Security.loadPolicyFile() method. A cross-domain policy file applies only to the directory from which it is
loaded and to its child directories. So a policy file in the root directory applies to the whole server, but a policy file
loaded from an arbitrary subdirectory applies only to that directory and its subdirectories.ADOBE FLEX 3
Developer Guide
541
A policy file affects access only to the particular server on which it resides. For example, a policy file located at
https://www.adobe.com:8080/crossdomain.xml will apply only to data- loading calls made to www.adobe.com over
HTTPS at port 8080.
A cross-domain 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 an 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 is 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.
You can permit access to documents originating from any domain, as shown in the following example:
<?xml version="1.0"?>
<!-- http://www.foo.com/crossdomain.xml -->
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Each <allow-access-from> tag also has the optional secure attribute, which defaults to true. You can set the
attribute to false if your policy file is on an HTTPS server, and you want to allow SWF files on a non-HTTPS server
to load data from the HTTPS server.
Setting the secure attribute to false could compromise the security offered by HTTPS. In particular, setting this
attribute to false opens secure content to snooping and spoofing attacks. Adobe strongly recommends that you not
set the secure attribute to false.
If data to be loaded is on a HTTPS server, but the SWF file loading it is on an HTTP server, Adobe recommends that
you move the loading SWF file to an HTTPS server so that you can keep all copies of your secure data under the
protection of HTTPS. However, if you decide that you must keep the loading SWF file on an HTTP server, add the
secure="false" attribute to the <allow-access-from> tag, as shown in the following code:
<allow-access-from domain="www.example.com" secure="false" />
A policy file that contains no <allow-access-from> tags has the same effect as not having a policy on a server.
Socket policy files
ActionScript objects instantiate two different kinds of server connections: document-based server connections and
socket connections. ActionScript objects like Loader, Sound, URLLoader, and URLStream instantiate documentbased server connections, and these each load a file from a URL. ActionScript Socket and XMLSocket objects make
socket connections, which operate with streaming data, not loaded documents. Flash Player supports two kinds of
policy files: document-based policy files and socket policy files. Document-based connections require documentbased policy files, while socket connections require socket policy files.
Flash Player requires that a policy file be transmitted using the same kind of protocol that the attempted connection
wishes to use. For example, when you place a policy file on your HTTP server, SWF files from other domains are
allowed to load data from it as an HTTP server. However, by not providing a socket policy file at the same server,
you are forbidding SWF files from other domains to connect to the server at the socket level. The means by which a
socket policy file is retrieved must match the means of connecting.ADOBE FLEX 3
Developer Guide
542
A policy file served by a socket server has the same syntax as any other policy file, except that it must also specify the
ports to which it grants access. When a policy file comes from a port number that is less than 1024, it may grant
access to any ports; when a policy file comes from port 1024 or higher, it may only grant access to ports 1024 and
higher. The allowed ports are specified in a to-ports attribute in the <allow-access-from> tag. Single port
numbers, port ranges, and wildcards are accepted values.
Here is an example XMLSocket policy file:
<cross-domain-policy>
<allow-access-from domain="*" to-ports="507" />
<allow-access-from domain="*.example.com" to-ports="507,516" />
<allow-access-from domain="*.example2.com" to-ports="516-523" />
<allow-access-from domain="www.example2.com" to-ports="507,516-523" />
<allow-access-from domain="www.example3.com" to-ports="*" />
</cross-domain-policy>
When policy files were first introduced in Flash Player 6, there was no support for socket policy files. Connections
to socket servers were authorized by a policy file from the default location of the cross-domain policy file on an
HTTP server on port 80 of the same host as the socket server. To make it possible to preserve existing server arrangements, Flash Player 9 still supports this capability. However, Flash Player’s default is now to retrieve a socket policy
file on the same port as the socket connection. If you wish to use an HTTP-based policy file to authorize a socket
connection, you must explicitly request the HTTP policy file using code such as the following:
Security.loadPolicyFile("http://socketServerHost.com/crossdomain.xml")
In addition, in order to authorize socket connections, an HTTP policy file must come only from the default location
of the cross-domain policy file, and not from any other HTTP location. A policy file obtained from an HTTP server
implicitly authorizes socket access to all ports 1024 and above; any to-ports attributes in an HTTP policy file are
ignored.
Preloading policy files
Loading data from a server or connecting to a socket is an asynchronous operation, and Flash Player simply waits
for the cross-domain policy file to finish downloading before it begins the main operation. However, extracting pixel
data from images or extracting sample data from sounds is a synchronous operation—the cross-domain policy file
must load before you can extract data. When you load the media, you need to specify that it check for a cross-domain
policy file:
• When using the Loader.load() method, set the checkPolicyFile property of the context parameter, which
is a LoaderContext object.
• When embedding an image in a text field using the <img> tag, set the checkPolicyFile attribute of the <img>
tag to "true", as in the following: <img checkPolicyFile = "true" src = "example.jpg">.
• When using the Sound.load() method, set the checkPolicyFile property of the context parameter, which
is a SoundLoaderContext object.
• When using the NetStream class, set the checkPolicyFile property of the NetStream object.
When you set one of these parameters, Flash Player first checks for any policy files that it already has downloaded
for that domain. Then it considers any pending calls to the Security.loadPolicyFile() method to see if they are
in scope, and waits for those if they are. Then it looks for the cross-domain policy file in the default location on the
server.
Connecting to sockets
Cross-domain access to socket and XML socket connections is disabled by default. Also disabled by default is access
to socket connections in the same domain as the SWF file on ports lower than 1024. You can permit access to these
ports by serving a cross-domain policy file from any of the following locations:
• The same port as the main socket connection
• A different port
• An HTTP server on port 80 in the same domain as the socket server
If you serve the cross-domain policy file from same port as the main socket connection, or in a different port, you
enumerate permitted ports by using a to-ports attribute in the cross-domain policy file, as the following example
shows:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domainpolicy.dtd">ADOBE FLEX 3
<!-- Policy file for xmlsocket://socks.mysite.com -->
<cross-domain-policy>
<allow-access-from domain="*" to-ports="507" />
<allow-access-from domain="*.example.com" to-ports="507,516" />
<allow-access-from domain="*.example.org" to-ports="516-523" />
<allow-access-from domain="adobe.com" to-ports="507,516-523" />
<allow-access-from domain="192.0.34.166" to-ports="*" />
</cross-domain-policy>
To retrieve a socket policy file from the same port as a main socket connection, simply call the Socket.connect()
or XMLSocket.connect() method, and, if the specified domain is not the same as the domain of the calling SWF
file, Flash Player automatically attempts to retrieve a policy file from the same port as the main connection you are
attempting. To retrieve a socket policy file from a different port on the same server as your main connection, call the
Security.loadPolicyFile() method with the special "xmlsocket" syntax, as in the following:
Security.loadPolicyFile("xmlsocket://server.com:2525");
Call the Security.loadPolicyFile() method before calling the Socket.connect() or XMLSocket.connect()
method. Flash Player then waits until it has fulfilled your policy file request before deciding whether to allow your
main connection.
If you are implementing a socket server and you need to provide a socket policy file, decide whether you will provide
the policy file using the same port that accepts main connections, or using a different port. In either case, your server
must wait for the first transmission from your client before deciding whether to send a policy file or set up a main
connection. When Flash Player requests a policy file, it always transmits the following string as soon as a connection
is established:
<policy-file-request/>
Once the server receives this string, it can transmit the policy file. Do not expect to reuse the same connection for
both a policy file request and a main connection; you should close the connection after transmitting the policy file.
If you do not, Flash Player closes the policy file connection before reconnecting to set up the main connection
No comments:
Post a Comment