Flash CS3 Documentation

Learning ActionScript 2.0 in Adobe Flash > Understanding Security > About domains, cross-domain security, and SWF files > Cross-domain and subdomain access between SWF files

Cross-domain and subdomain access between SWF files

When you develop a series of SWF files that communicate with each other online--for example, when using loadMovie(), MovieClip.loadMovie(), MovieClipLoader.LoadClip(), or Local Connection objects--you might host the SWF files in different domains or in different subdomains of a single superdomain.

In files published for Flash Player 5 or earlier, there were no restrictions on cross-domain or subdomain access.

In files published for Flash Player 6, you could use the LocalConnection.allowDomain handler or System.security.allowDomain() method to specify permitted cross-domain access (for example, to let a file at adobe.com be accessed by a file at helpexamples.com), and no command was needed to permit subdomain access (for example, a file at www.adobe.com could be accessed by a file at something.adobe.com).

Files published for Flash Player 7 implement access between SWF files differently from earlier versions in two ways. First, Flash Player 7 implements exact-domain matching rules instead of superdomain matching rules. Therefore, the file being accessed (even if it is published for a Flash Player version earlier than Flash Player 7) must explicitly permit cross-domain or subdomain access; this topic is discussed in this section. Second, a file hosted at a site using a secure protocol (HTTPS) must explicitly permit access from a file hosted at a site using an insecure protocol (HTTP or FTP); this topic is discussed in the next section (see HTTP to HTTPS protocol access between SWF files).

You usually call System.security.allowDomain in your applications. However, when the LocalConnection receiver is an HTTPS SWF file and the sender is not, allowInsecureDomain is called instead.

The following issue affects only SWF files published for Flash Player 7. When the receiver is HTTPS, and the sender is a local SWF file, allowDomain() is called, even though allowInsecureDomain() should be called. However, in Flash Player 8 and later, when an HTTPS LocalConnection receiver is Flash Player 8 and later, and the sender is a local file, allowInsecureDomain() is called.

Files that run in Flash Player 8 and later are subject to changes from how they run in Flash Player 7. Calling System.security.allowDomain permits cross-scripting operations only where the SWF file being accessed is the one that called System.security.allowDomain. In other words, a SWF file that calls System.security.allowDomain now permits access only to itself. In previous versions, calling System.security.allowDomain permitted cross-scripting operations where the SWF file being accessed could be any SWF file in the same domain as the one that called System.security.allowDomain. Doing so opened up the entire domain of the calling SWF file.

Support has been added for the wildcard (*) value to System.security.allowDomain("*") and System.security.allowInsecureDomain("*"). The wildcard (*) value permits cross-scripting operations where the accessing file is any file and can be loaded from any location (such as global permission). Wildcard permissions can be useful, but they must adhere to the new local file security rules in Flash Player 8 and later. Specifically, local files do not come from a domain, so the wildcard value must be used. However, use caution when using the wildcard value because any domain has access to your file. For more information, see allowInsecureDomain (security.allowInsecureDomain method).

You might encounter a situation when you load a child SWF file from a different domain than the one calling it. You might want to allow that file to script the parent SWF file, but you don't know the final domain from which the child SWF file will come. This situation can happen, for example, when you use load-balancing redirects or third-party servers. In this situation, you can use the MovieClip._url property as an argument to this method. For example, if you load a SWF file into my_mc, you can call System.security.allowDomain(my_mc._url). If you do this, you must wait until the SWF file in my_mc begins loading because the _url property does not have its final, correct value yet. To determine when a child SWF file has started to load, use MovieClipLoader.onLoadStart.

The opposite situation can also occur; that is, you might create a child SWF file that wants to allow its parent to script it, but doesn't know what the domain of its parent SWF file will be (meaning, it's a SWF file that might be loaded by a variety of domains). In this situation, call System.security.allowDomain(_parent._url) from the child SWF file. You don't have to wait for the parent SWF file to load because it is loaded before the child file loads.

The following table summarizes domain-matching rules in different versions of Flash Player:

The versions that control the behavior of Flash Player are SWF file versions (the specified Flash Player version of a SWF file), not the version of Flash Player itself. For example, when Flash Player 8 and later is playing a SWF file published for version 7, Flash Player applies behavior that is consistent with version 7. This practice ensures that player upgrades do not change the behavior of System.security.allowDomain() in deployed SWF files.

Because Flash Player 7 and later versions implement exact-domain matching rules instead of superdomain matching rules, you might have to modify existing scripts if you want to read them from files that are published for Flash Player 7 and later. (You can still publish the modified files for Flash Player 6.) If you used any LocalConnection.allowDomain() or System.security.allowDomain() statements in your files and specified superdomain sites to permit, you must change your parameters to specify exact domains instead. The following example shows changes you might have to make if you have Flash Player 6 code:

// Flash Player 6 commands in a SWF file at www.helpexamples.com 
// to allow access by SWF files that are hosted at www.adobe.com
// or at store.adobe.com
System.security.allowDomain("adobe.com");
my_lc.allowDomain = function(sendingDomain) {    
    return(sendingDomain=="adobe.com");
}
// Corresponding commands to allow access by SWF files
// that are published for Flash Player 7 or later
System.security.allowDomain("www.adobe.com", "store.adobe.com");
my_lc.allowDomain = function(sendingDomain) {    
    return(sendingDomain=="www.adobe.com" ||
        sendingDomain=="store.adobe.com");
}

You might also have to add statements such as these to your files if you aren't currently using them. For example, if your SWF file is hosted at www.adobe.com and you want to allow access by a SWF file published for Flash Player 7 or later at store.adobe.com, you must add statements such as the following example to the file at www.adobe.com (you can still publish the file at www.adobe.com for Flash Player 6):

System.security.allowDomain("store.adobe.com");
my_lc.allowDomain = function(sendingDomain) {    
    return(sendingDomain=="store.adobe.com");
}

In addition, consider that if a Flash Player 6 application running in Flash Player 7 tries to access data outside its exact domain, Flash Player 7 and later domain-matching rules are enforced and the user is prompted to allow or deny access.

To summarize, you might have to modify your files to add or change allowDomain statements if you publish files for Flash Player 7 or later that meet the following conditions:

• You implemented cross-SWF file scripting (see Allowing data access between cross-domain SWF files).
• The called SWF file (of any version) is not hosted at a site using a secure protocol (HTTPS), or the calling and called SWF files are both hosted at HTTPS sites. (If only the called SWF file is HTTPS, see HTTP to HTTPS protocol access between SWF files.)
• The SWF files are not in the same domain (for example, one file is at www.adobe.com and one is at store.adobe.com).

You must make the following changes:

• If the called SWF file is published for Flash Player 7 or later, include System.security.allowDomain or LocalConnection.allowDomain in the called SWF file, using exact domain-name matching.
• If the called SWF file is published for Flash Player 6, modify the called file to add or change a System.security.allowDomain or LocalConnection.allowDomain statement, using exact domain-name matching, as shown in the code examples earlier in this section. You can publish the modified file for either Flash Player 6 or 7.
• If the called SWF file is published for Flash Player 5 or earlier, port the called file to Flash Player 6 or 7 and add a System.security.allowDomain statement, using exact domain-name matching, as shown in the code examples earlier in this section. (LocalConnection objects aren't supported in Flash Player 5 or earlier.)

For information on local security sandboxes, see About local file security and Flash Player.

Flash CS3

Comments

Add Comment

flashizzle said on Oct 19, 2007 at 4:20 PM :

I can not find documentation on this _anywhere_, but in my testing it is clear
the .swf files loaded from different domains do NOT share the same _global
scope, even after allowDomain("*") has been called. So if _parent.swf
assigns _global.foo = "123" ... child.swf will always see _global.foo as
"undefined", unless both .swfs share the exact same domain. Ugh!

jaw-writer said on Oct 25, 2007 at 1:37 PM :

Cross-domain SWFs can never share the same _global object. Every domain gets its own global object.

dt voyageur said on Mar 24, 2008 at 1:55 PM :

The same seems to be true of using the Delegate class for events fired in one domain where the handler is in another. I've got two .swfs loading into a base .swf in which an EventDispatcher instance resides. Even though the events fired directly from the base .swf get sent to the Delegate in A.swf, events fired from B.swf (which is actually in the base.swf domain) don't make it if a Delegate is used. If I don't use the delegate, it works fine... even after system.allowDomain("*")

 

RSS feed | Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/flash/9.0/main/00001082.html

Add Comment