An important property of a Loader object is the contentLoaderInfo property, which is a
LoaderInfo object. Unlike most other objects, a LoaderInfo object is shared between the loading SWF file and the loaded content, and it is always accessible to both parties. When the loaded content is a SWF file, it can access the LoaderInfo object through the
DisplayObject.loaderInfo
property. LoaderInfo objects include information such as load progress, the URLs of loader and loadee, the trust relationship between loader and loadee, and other information. For more information, see “The LoaderInfo class” on page 180 .
Loading sound and videos
All SWF files, other than those in the local-with-filesystem sandbox, are allowed to load sound and video from network origins, using the Sound.load() ,
NetConnection.connect() , and NetStream.play() methods.
Only local SWF files can load media from the local file system. Only SWF files in the localwith-filesystem sandbox or the local-trusted sandbox can access data in these loaded files.
There are other restrictions on accessing data from loaded media. For details, see “Accessing loaded media as data” on page 474 .
Loading SWF files and images using the <img> tag in a text field
You can load SWF files and bitmaps into a text field by using the <img> tag, as in the following code:
<img src = 'filename.jpg' id = 'instanceName' >
You can access content loaded this way by using the getImageReference() method of the
TextField instance, as in the following code: var loadedObject:DisplayObject = myTextField.getImageReference('instanceName');
Note, however, that SWF files and images loaded in this way are put in the sandbox that corresponds to their origin.
When you load an image file using an <img> tag in a text field, access to the data in the image may be permitted by a cross-domain policy file. You can check for a policy file by adding a checkPolicyFile attribute to the <img> tag, as in the following code:
<img src = 'filename.jpg' checkPolicyFile = 'true' id = 'instanceName' >
When you load a SWF using an <img> tag in a text field, you can permit access to that SWF file’s data through a call to the Security.allowDomain() method.
Loading content 469
When you use an <img> tag in a text field to load an external file (as opposed to using a
Bitmap class embedded within your SWF), a Loader object is automatically created as a child of the TextField object, and the external file is loaded into that Loader just as if you had used a Loader object in ActionScript to load the file. In this case, the getImageReference() method returns the Loader that was automatically created. No security check is needed to access this Loader object because it is in the same security sandbox as the calling code.
However, when you refer to the content property of the Loader object to access the loaded media, security rules apply. If the content is an image, you need to implement a cross-domain policy file, and if the content is a SWF file, you need to have the code in the SWF file call the allowDomain() method.
Content delivered using RTMP servers
Flash Media Server uses the Real-Time Media Protocol (RTMP) to serve data, audio, and video. A SWF file loads this media by using the connect() method of the NetConnection class, passing an RTMP URL as the parameter. Flash Media Server can restrict connections and prevent content from downloading, based on the domain of the requesting file. For details, see the Flash Media Server documentation.
For media loaded from RTMP sources, you cannot use the BitmapData.draw() and
SoundMixer.computeSpectrum() methods to extract run-time graphics and sound data.
Cross-scripting
If two SWF files written with ActionScript 3.0 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 one SWF file can examine and modify variables, objects, properties, methods, and so on in the other, and vice versa. This is called cross-scripting .
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.
470 Flash Player Security
If two SWF files written with ActionScript 3.0 are served from different domains—for example, http://siteA.com/swfA.swf and http://siteB.com/swfB.swf—then, by default, Flash
Player does 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.
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: siteA.com / swfA.swf
SWF var url:String = "http://siteB.com/swfB.swf"; var req:URLRequest = new URLRequest(url); myLoader.load(req); myLoader.content.eggCount = 3; myLoader.content.DisplayEggs();
3 cross-script
2 permission
Security.allowDomain("siteA.com");
1 load var eggCount:Number; function DisplayEggs() { ... }; siteB.com / swfB.swf
SWF
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.
Cross-scripting 471
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” on page 460 .
Also, Flash Player provides security controls for SWF-to-HTML scripting. For more information, see “Controlling access to scripts in a host web page” on page 481 .
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 align displayState frameRate height mouseChildren numChildren quality scaleMode showDefaultContextMenu stageFocusRect stageHeight stageWidth tabChildren textSnapshot width
Methods addChild() addChildAt() addEventListener() dispatchEvent() hasEventListener() setChildIndex() willTrigger()
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” on page 460 .
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.
472 Flash Player Security
