<a target="_blank" href="http://www.crossdomainxml.org/">http://www.crossdomainxml.org/</a>
别的废话不多说了,上面的网址很全。
为还存在疑惑“怎么不起作用呀”的网友补充几句话。
首先,crossdomain.xml是放在服务器端的文件,什么叫做放在服务器端,就是放在你要获取的文件的所在的那台机器的那个域名下面。比如我自己的网站是xxx.me.com,我的网站上有一个swf要获取xxx.you.com上的文件,那么crossdomain.xml要放在xxx.you.com上才可以。crossdomain.xml里面的内容就是
<code><?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*.me.com" /> </cross-domain-policy></code>
明白了吧。
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Adobe
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security.html">Introduction</a>
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security_02.html">Changes in behavior due to immediate strictness</a>
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security_03.html">Meta-policies</a>
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security_04.html">Socket policy files</a>
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security_05.html">Workflows</a>
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security_06.html">Appendix A: Browser dependencies</a>
<a href="http://www.cnblogs.com/devnet/flashplayer/articles/fplayer9_security_07.html">Appendix B: Log message reference</a>
<a href="http://www.cnblogs.com/jiahuafu/admin/fplayer9_security_print.html">Printable version</a>
<a href="http://www.cnblogs.com/cfusion/mmform/index.cfm?name=brc_tutorial_feedback">Send feedback</a>
<a href="http://www.cnblogs.com/cfusion/resourcecenter/rc_driver.cfm?pagename=des_dev_nl">Get an e-mail update of new articles</a>
<a target="_blank" href="http://www.addthis.com/bookmark.php"></a>
<dl></dl>
<dt>Created: </dt>
<dd>3 December 2007 </dd>
<dt>Modified: </dt>
<dd>24 October 2008 </dd>
<dt>User Level: </dt>
<dd>Intermediate </dd>
<dt>Products: </dt>
<dd>Flash Player</dd>
This article refers to Flash Player 9 Update 3 (9,0,115,0), Flash Player 9 April 2008 Security Update (9,0,124,0), and Flash Player 10.0 (10,0,2,xx and later).
Note: This article was updated in October 2008. There are only three substantial changes to be aware of: Flash Player 9,0,124,0 has implemented fully strict behavior for sockets (Phase 1.5); Flash Player 10.0 has implemented Phase 2 of the new restrictions; and the Phase 2 default URL meta-policy has been changed from the maximally restrictive <code>none</code> to the less restrictive <code>master-only</code>, permitting URL master policy files (those at /crossdomain.xml) to continue working without the introduction of a meta-policy.
In 2003, Flash Player 7 software introduced a channel of client-server communication that was new to the web: direct cross-domain data loading, authorized by policy files. Before policy files, web content could only perform two-way communication with its own server, such as runtime configuration or transactions without page reloads. Policy files allowed servers to open up their data selectively to client content from other domains, or generally to content from anywhere. Since the introduction of policy files, domain boundaries have been less of a barrier for authors of rich Internet applications.
Like most new technologies, policy files weren't perfect when they were first introduced. After four years, the Internet security community has found two undesirable situations (described later in this article) that can arise from the existence of policy files. The basic premise of policy files remains valid, and Flash developers can continue to rely on policy files just as they have since Flash 6. To address the new concerns, however, Adobe is specifying some stricter rules for the use of policy files. Additionally, there are a number of improvements that make policy files more useful and usable. We will try to explain the reasons for our changes clearly and simply.
To conform to the stricter rules, websites that serve policy files will need to make some minor changes. These changes are mainly for the protection of those sites themselves—essentially a new set of security best practices concerning policy files.
For most sites, we don't expect the changes to be difficult—but because of the large number of sites impacted, Adobe implemented the stricter requirements in Flash Player in three phases. In Phase 1, which began with Flash Player 9,0,115,0, a small number of strict rules were enforced immediately, but most violations of the strict rules resulted only in warnings visible in Debug versions of Flash Player. In Phase 1.5, which began with Flash Player 9,0,124,0, the warnings of Phase 1 became errors in the specific case of socket operations. In Phase 2, which began with Flash Player 10.0, all of the warnings of Phase 1 became errors and the transition to stricter rules was complete.
We recommend that website administrators follow these steps:
Two issues are addressed by the stricter policy file rules:
While addressing the above issues, we have also added some new features to make policy files more useful and usable:
<dt>Page 1 of 7 </dt>
<dd></dd>
<a href="http://www.cnblogs.com/jiahuafu/admin/fplayer9_security_02.html">Next Page</a>
Deneb Meketa is an engineer on the Adobe Flash Player team. He never set out to be the Security Guy, but that's kinda what he's turned into. He swears that he gets no pleasure out of inflicting security rules on the world, and wishes that the Bad People would chill out and leave us all alone. Nevertheless, he has a lot of fun working on the internals of Flash Player, which is a really cool piece of software.