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)
to wait for the parent SWF file to load because it is loaded before the child file loads.
If the Internet SWF file being accessed is loaded from an HTTPS URL, the Internet SWF
file must call
System.security.allowInsecureDomain("*")
The following table summarizes domain-matching rules in different versions of Flash Player:
Files published for
Flash Player
5 or earlier
6
7 and later
You need
System.security.allowInsecureDomain
performing HTTP-to-HTTPS access, even if you have exact-domain matching.
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 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()
698
Understanding Security
Cross-domain access
between SWF files
(allowDomain() is needed)
No restrictions
Superdomain matching:
is needed if
allowDomain()
superdomains do not match.
Exact domain matching
Explicit permission for HTTPS-
hosted files to access HTTP- or
FTP-hosted files
from the child SWF file. You don't have
.
Subdomain access
between SWF files
No restrictions
No restrictions
Exact domain matching
Explicit permission for HTTPS-
hosted files to access HTTP- or
FTP-hosted files
in Flash Player 7 and later if you are
in deployed SWF files.
Need help?
Do you have a question about the FLASH 8-LEARNING ACTIONSCRIPT 2.0 IN FLASH and is the answer not in the manual?
Questions and answers