Flash CS3 Documentation
|Programming ActionScript 3.0 > Flash Player security > Controlling access to scripts in a host web page|
Revised 4/6/08 to clarify that the information on this page applies to all types of outbound URL access, not just scripts. Made several additions and corrections throughout this page.
Outbound scripting and URL access (through the use of HTTP URLs,
mailto: and so on) are achieved through use of the following ActionScript 3.0 APIs:
For SWF files running locally, calls to these APIs are sucessful only if the SWF file and the containing web page (if there is one) are in the local-trusted security sandbox. Calls to these methods fail if the content is in the local-with-networking or local-with-filesystem sandbox.
For SWF files that are not running locally, all of these APIs can communicate with the web page in which they are embedded, depending on the value of the
AllowScriptAccess parameter described below. The
flash.net.navigateToURL() function has the additional ability to communicate with any open browser window or frame, not just the page in which the SWF file is embedded. For more information on this functionality, see Using the
AllowScriptAccess parameter in the HTML code that loads a SWF file controls the ability to perform outbound URL access from within the SWF file. Set this parameter inside the
EMBED tag. If no value is set for
AllowScriptAccess, the SWF file and the HTML page can communicate only if both are from the same domain.
AllowScriptAccess parameter can have one of three possible values:
"never". Revised 4/16/08 to reflect changes in the use of the value
"always", the SWF file can communicate with the HTML page in which it is embedded even when the SWF file is from a different domain than the HTML page.
"sameDomain", the SWF file can communicate with the HTML page in which it is embedded only when the SWF file is from the same domain as the HTML page. This is the default value for
AllowScriptAccess. Use this setting, or do not set a value for
AllowScriptAccess, to prevent a SWF file hosted from one domain from accessing a script in an HTML page that comes from another domain.
"never", the SWF file cannot communicate with any HTML page. Using this value is deprecated and not recommended, and shouldn’t be necessary if you don’t serve untrusted SWF files from your own domain. If you do need to serve untrusted SWF files, Adobe recommends that you create a distinct subdomain and place all untrusted content there.
Here is an example of setting the
AllowScriptAccess tag in an HTML page to allow outbound URL access to a different domain:
<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'> <param name='AllowScriptAccess' value='always'/> <param name='src' value=''MyMovie.swf'/> <embed name='MyMovie.swf' pluginspage='http://www.adobe.com/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' AllowScriptAccess='always'/> </object>
In addition to the security setting specified by the
allowScriptAccess parameter discussed above, the
navigateToURL() function has an optional second parameter -
target - that can be used to specify the name of an HTML window or frame to send the URL request to. Additional security restrictions apply to such requests, and the restrictions vary depending on whether
navigateToURL() is being used as a scripting or non-scripting statement.
For scripting statements, such as
allowScriptAccessrules described above apply.
For non-scripting statements (HTTP, HTTPS,
mailto: and so on), the request fails if all of the following conditions apply:
allowScriptAccessthat is not
call()method of the ExternalInterface class
Send me an e-mail when comments are added to this page | Comment Report
Current page: http://livedocs.adobe.com/flash/9.0/main/00000360.html