Issue

In Flash Player 9, the Sound.id3 property is not available when using Sound.loadSound (or its ActionScript 3.0 equivalent, Sound.load) to load an external MP3 file from a different domain than the Flash Player movie (SWF) file unless a policy file exists on the MP3 file's server. The policy file must permit access by the domain of the SWF that is attempting to read ID3 tag information from the MP3 file.

This may cause some MP3 files to appear not to contain any ID3 tag information.

Reason

Flash Player enforces security sandbox boundaries between media loaded from different domains. These boundaries typically permit media to be played from other domains, but generally prevent data from being extracted from that media into ActionScript. For example, Flash Player permits SWF files to load and display SWF files from other domains, but does not permit a SWF file to inspect the variables of a SWF file from a different domain unless the SWF file being accessed has calledSystem.security.allowDomain (or, in ActionScript 3.0,Security.allowDomain) to permit the access.

Starting in Flash Player 9, Sound.id3 is recognized as an operation that extracts data from MP3 media, and thus is prohibited for MP3 files from different domains, except where a policy file on an MP3 file's server permits the operation.

This is a new behavior introduced in Flash Player 9 to comply with the security model and affects all SWF versions. Adobe is aware that this may change the behavior of some SWF media deployed before the release of Flash Player 9, and we apologize for any inconvenience this may cause.

Solution

We will use the following example to illustrate the possible workarounds. If you maintain a SWF file at http://www.mysite.com/mySwf.swf that loads an MP3 file from http://www.anothersite.com/sounds/aSound.mp3, and you need to be able to extract ID3 tag information from a Sound.mp3, there are several workarounds that may be applied.

Create a default-location policy file

The easiest fix is to create a policy file in the default location on www.anothersite.com, as in the following example:

<!-- Cross-domain policy file at http://anothersite.com/crossdomain.xml -->
<cross-domain-policy>
   <allow-access-from domain="www.mysite.com"/>
</cross-domain-policy> 

You should not create a policy file on www.anothersite.com unless you are sure that all SWF files that might originate from www.mysite.com are trustworthy;that is, you control www.mysite.com, or you trust the person or people that do. Creating a policy file has additional effects beyond permitting cross-domain ID3 tag access;for example, a SWF file from www.mysite.com will also be permitted to read the contents of any text files on anothersite.com, and send those contents anywhere it chooses.

In particular, it is never advisable to create a policy file on a server on a private network that is not accessible from the Internet.

By using the default policy file location, which is a file called "crossdomain.xml" in the root directory of the web server at anothersite.com, you permit cross-domain ID3 access without having to inform Flash Player of the policy file's location. However, the default location speaks for the entire web server, so only use the default location if you want to permit access to the entire contents of the web server by SWFs from the domain(s) you name in your policy file.

Even if you use the default policy file location, there is one modification that you will need in your SWF file: you must set theSound.checkPolicyFile flag before callingSound.loadSound. This instructs Flash Player not to begin downloading the MP3 file until after attempting to download a policy file. The advantage of this is that you can be assured that, once MP3 data begins downloading, it is safe to refer toSound.id3. If you do not specifySound.checkPolicyFile, Flash Player will not be aware that you intend to refer to Sound.id3, and thus will not preload a policy file; and, since Sound.id3 is a synchronous API, Flash Player cannot retrieve a policy file at that moment.

Here is an example (in ActionScript 2.0) of usingSound.checkPolicyFile with a default policy file:

var mySound : Sound = new Sound(); 
mySound.checkPolicyFile = true; 
mySound.loadSound("http://anothersite.com/sounds/aSound.mp3"); 

Create a custom-location policy file

If you do not have access to the root directory of the web server at anothersite.com, or you do not want to permit access to all of anothersite.com, but only a part of it, then you can create a policy file in any location that you want on anothersite.com. The location of the policy file will determine its scope;for example, if you create a policy file in a subdirectory http://anothersite.com/sounds/crossdomain.xml, that policy file will apply to media located in the subdirectory athttp://anothersite.com/sounds/ and below. The contents of the policy file would be the same as in part (1) above.

When you use a non-default location, you must inform Flash Player of the non-default location, by callingSystem.security.loadPolicyFile (or, in ActionScript 3.0, Security.loadPolicyFile). In addition, you should set the Sound.checkPolicyFile flag, to request that Flash Player finish the policy file download attempt before beginning the MP3 download. Here is an example (in ActionScript 2.0):

System.security.loadPolicyFile("http://anothersite.com/sounds/crossdomain.xml"); 
var mySound : Sound = new Sound();    
mySound.checkPolicyFile = true; 
mySound.loadSound("http://anothersite.com/sounds/aSound.mp3"); 

Proxy the MP3 download through the SWF file's own server

If you do not have control over the server from which you are loading an MP3 file, but you need to extract ID3 tag information from the MP3 file, you can proxy the MP3 download through the server from which your SWF file is served. You might do this with a CGI script on your own server, invoking the script like this:

 mySound.loadSound("http://mysite.com/cgi-bin/proxy.cgi" + "?url=http://anothersite.com/sounds/aSound.mp3"); 

This is always permitted, since a SWF file may always access data from its own server. However, this requires some server-side scripting, using CGI, perl, PHP, ColdFusion, ASP, or any server scripting technology.

Be careful when you set up a proxying script like this, as there are many other security considerations for proxies. You will probably want to take at least some basic steps to ensure that the proxy is only used for the purposes for which you intend it. These could include checking HTTP "Referer" headers, hard-coding a limited range of URLs that the script will retrieve, etc.

Products affected