If two SWF files
written with ActionScript 3.0, or two HTML files running in AIR
are served from the same domain—for example, the URL for one SWF
file is http://www.example.com/swfA.swf and the URL for the other
is http://www.example.com/swfB.swf—then code defined in one file
can examine and modify variables, objects, properties, methods,
and so on in the other, and vice versa. This is called
cross-scripting
.
If the two files are
served from different domains—for example, http://siteA.com/swfA.swf
and http://siteB.com/swfB.swf—then, by default, Flash Player and
AIR do not allow swfA.swf to script swfB.swf, nor swfB.swf to script
swfA.swf. A SWF file gives permission to SWF files from other domains
by calling
Security.allowDomain()
. By calling
Security.allowDomain("siteA.com")
,
swfB.swf gives SWF files from siteA.com permission to script it.
Cross-scripting is not supported between AVM1 SWF files and AVM2
SWF files. An AVM1 SWF file is one created by using ActionScript
1.0 or ActionScript 2.0. (AVM1 and AVM2 refer to the ActionScript
Virtual Machine.) You can, however, use the LocalConnection class
to send data between AVM1 and AVM2.
In any cross-domain situation, it is important to be clear about
the two parties involved. For the purposes of this discussion, the
side that is performing the cross-scripting is called the
accessing party
(usually
the accessing SWF), and the other side is called the
party being accessed
(usually
the SWF being accessed). When siteA.swf scripts siteB.swf, siteA.swf
is the accessing party, and siteB.swf is the party being accessed,
as the following illustration shows:
Cross-domain permissions that are established with the
Security.allowDomain()
method
are asymmetrical. In the previous example, siteA.swf can script
siteB.swf, but siteB.swf cannot script siteA.swf, because siteA.swf
has not called the
Security.allowDomain()
method
to give SWF files at siteB.com permission to script it. You can
set up symmetrical permissions by having both SWF files call the
Security.allowDomain()
method.
In addition to protecting SWF files from
cross-domain scripting originated by other SWF files, Flash Player
protects SWF files from cross-domain scripting originated by HTML
files. HTML-to-SWF scripting can occur with callbacks established through
the
ExternalInterface.addCallback()
method. When
HTML-to-SWF scripting crosses domains, the SWF file being accessed
must call the
Security.allowDomain()
method, just
as when the accessing party is a SWF file, or the operation will
fail. For more information, see
Author (developer) controls
.
Also, Flash Player provides security controls for SWF-to-HTML
scripting. For more information, see
Controlling outbound URL access
.
Stage security
Some
properties and methods of the Stage object are available to any
sprite or movie clip on the display list.
However, the Stage object is said to have an owner: the first
SWF file loaded. By default, the following properties and methods
of the Stage object are available only to SWF files in the same
security sandbox as the Stage owner:
|
Properties
|
Methods
|
|
align
|
addChild()
|
|
displayState
|
addChildAt()
|
|
frameRate
|
addEventListener()
|
|
height
|
dispatchEvent()
|
|
mouseChildren
|
hasEventListener()
|
|
numChildren
|
setChildIndex()
|
|
quality
|
willTrigger()
|
|
scaleMode
|
|
|
showDefaultContextMenu
|
|
|
stageFocusRect
|
|
|
stageHeight
|
|
|
stageWidth
|
|
|
tabChildren
|
|
|
textSnapshot
|
|
|
width
|
|
In order for a SWF file in a sandbox other than that of the Stage
owner to access these properties and methods, the Stage owner SWF
file must call the
Security.allowDomain()
method
to permit the domain of the external sandbox. For more information,
see
Author (developer) controls
.
The
frameRate
property is a special case—any
SWF file can read the
frameRate
property. However,
only those in the Stage owner’s security sandbox (or those granted
permission by a call to the
Security.allowDomain()
method)
can change the property.
There are also restrictions on the
removeChildAt()
and
swapChildrenAt()
methods
of the Stage object, but these are different from the other restrictions.
Rather than needing to be in the same domain as the Stage owner,
to call these methods code must be in the same domain as the owner
of the affected child object(s), or the child object(s) can call
the
Security.allowDomain()
method.
Traversing the display list
The ability of one SWF file to access display
objects loaded from other sandboxes is restricted. In order for
a SWF file to access a display object created by another SWF file
in a different sandbox, the SWF file being accessed must call the
Security.allowDomain()
method
to permit access by the domain of the accessing SWF file. For more
information, see
Author (developer) controls
.
To access a Bitmap object that was loaded by a Loader object,
a URL policy file must exist on the origin server of the image file,
and that policy file must grant permission to the domain of the
SWF file trying to access the Bitmap object (see
Website controls (policy files)
).
The LoaderInfo object
that corresponds to a loaded file (and to the Loader object) includes
the following three properties, which define the relationship between the
loaded object and the Loader object:
childAllowsParent
,
parentAllowsChild
,
and
sameDomain
.
Event security
Events related to the display list have
security access limitations, based on the sandbox of the display
object that is dispatching the event. An event in the display list
has bubbling and capture phases (described in
Handling events
). During the bubbling and capture phases, an event
migrates from the source display object through parent display objects
in the display list. If a parent object is in a different security
sandbox than the source display object, the capture and bubble phase
stops below that parent object, unless there is mutual trust between
the owner of the parent object and the owner of the source object.
This mutual trust can be achieved by the following:
-
The SWF file that owns the parent object must call the
Security.allowDomain()
method
to trust the domain of the SWF file that owns the source object.
-
The SWF file that owns the source object must call the
Security.allowDomain()
method
to trust the domain of the SWF file that owns the parent object.
The LoaderInfo object that corresponds
to a loaded file (and to the Loader object) includes the following
two properties, which define the relationship between the loaded
object and the Loader object:
childAllowsParent
and
parentAllowsChild
.
For events that are dispatched from objects other than display
objects, there are no security checks or security-related implications.
