Today, I updated my Flash Player plugin to version 10.0.42.34. Then it turns out that a DVF that was previously running locally is running today and throwing an exception. The prompt message is as follows:
SecurityError: Error # 2060: security sandbox conflict: the ExternalInterface caller file://D:/study/flex/service/bin/rainbowX.swf file://D:/study/flex/service/bin/rainbowX_Debug.html can be accessed. at flash.external::ExternalInterface$/_initJS() at flash.external::ExternalInterface$/addCallback() at freeidea.rainbowX::Application()
According to the prompt of debugging information because calls the ExternalInterface. AddCallback method. I take a look at the help documentation, which describes how this method throws a security exception as follows:
trigger
Error — this container does not support incoming calls. Incoming calls are supported only in Internet Explorer for Windows and browsers that use the NPRuntime API, such as Mozilla 1.7.5 and later or Firefox 1.0 and later.
0 SecurityError 1 — ActionScript in the sandbox where you have no access has added a callback with the specified name; You cannot override the callback. To solve this problem, rewrite the ActionScript that originally called the addCallback() so that it also calls the security.allowdomain () .
SecurityError - contains the environment belongs to the calling code has no right to access security sandbox. To solve this problem, follow these steps:
in the HTML page containing the SWF file, set the following parameters in the object tag of the file: < param name="" value="always" /> in the SWF file, add the following ActionScript: flash. System. Security. AllowDomain (sourceDomain)
Looking at the help instructions above, I think it may be due to cross-domain access issues, as mentioned in the article author (Developer) Control that if SWF wants to communicate with HTML scripts, then the value of allowScriptAccess for the plug-in must be set to Always. And SWF to allow access to the domain. So I try to join in the SWF flash system. Security. AllowDomain (" * "); Then add < < < param name="allowScriptAccess" value="always" /> This sentence. but the problem is still unresolved. There's no other way to think about it. Later, I found that my DVF could be browsed in the output folder of Project (I built it with Flex), but once I moved to another directory, it was not ok. As a result, I looked up the data and saw the following article, which was called "Overview of Permission Control". This article mainly shows what the Flash Player security model looks like. Below I put up part of the content, interested friends can go to the Internet search. overview of permission control Flash Player client runtime security model is a model designed around object resources such as SWF files, local data, and Internet urls. "Resource holders" means the parties that own or use these resources. Resource holders have control over their own resources (security Settings), and each resource has four holders. Flash Player USES a strict hierarchy of rights for these controls, as shown in the figure below:
security control hierarchy
the figure shows that if an administrator restricts access to a resource, no other holder can override the restriction. administrative user control
The administrative user of the computer (the user logging in with administrative privileges) can apply Flash Player security Settings that affect all users of the computer. In a non-enterprise environment, such as a home computer, there is usually only one user, who also has administrative access. Even in an enterprise environment, a single user can have computer administration rights.
There are two types of administrative user control: MMS. CFG file "global Flash Player trust" directory MMS. CFG file on Mac OS X, the MMS. CFG file is located in /Library/Application Support/Macromedia. On Microsoft Windows system, the file is located in the system directory of the Macromedia Flash Player folder (for example, in the default install Windows XP to C:/Windows/system32/macromed/Flash/MMS CFG). Flash Player will read its security Settings from this file when it starts, and then use these Settings to restrict the functionality.
The MMS. CFG file includes Settings that the administrator USES to perform the following tasks: data loading - restricts reading of local SWF files, prohibits file downloading and uploading, and sets storage limits on permanent Shared objects. privacy controls - disable microphone and camera access, prohibit SWF files from playing windowless content, and prohibit SWF files from accessing permanently Shared objects in domains that do not match the URL displayed in the browser window. Flash Player updates - sets the time interval to check Flash Player updates, specifies the URL to use to check Flash Player updates, specifies the URL from which to download Flash Player updates, and completely disables automatic Flash Player updates. older file support - specifies whether earlier versions of SWF files should be placed in a trusted local sandbox. local file security - specifies whether a local file can be placed in a trusted local sandbox. full screen mode - disable full screen mode. SWF file can be by calling the "Capabilities. AvHardwareDisable and " Capabilities. LocalFileReadDisable property to access functionality disabled some of the information. However, most of the Settings in the MMS.cfg file cannot be queried through ActionScript. is to enforce application-independent security and privacy policies on the computer, and only the mms.cfg file can be modified by the system administrator. The MMS. CFG file cannot be used to install the application. While an installer running with administrative permissions can modify the contents of the MS.cfg file, Adobe considers such use a violation of the user's trust and advises the creator of the installer never to modify the MS.cfg file. global Flash Player trust directory
The administrative user and installation application can register the specified local SWF file as trusted. These SWF files are assigned to trusted local sandboxes. They can interact with any other SWF file or load data from anywhere (remote or local). The file is specified as trusted in the global Flash Player trust directory, the same directory as the mms.cfg file, in the location (specific to the current user) as follows:
The Windows: the system/Macromed/Flash/FlashPlayerTrust (for example, C:/Windows/system32/Macromed/Flash/FlashPlayerTrust) Mac: App support/Macromedia FlashPlayerTrust (for example,/Library/Application support/Macromedia/FlashPlayerTrust)
The Flash Player trust directory can contain any number of text files, with each file listing the trusted path on one line. Each path can be a single SWF file, HTML file, or directory. Comment lines start with #. For example, a Flash Player trust profile with the following text indicates that trusted status is granted to all files in the specified directory and all subdirectories:
# Trust files in the following directories:
C:/Documents and Settings/All Users/Documents/SampleApp
The path listed in the trust profile should always be the local path or the SMB network path. Any HTTP path in the trust profile will be ignored; Only local files can be trusted. to avoid conflicts, specify a filename for each trust profile that corresponds to the installed application, and use the.cfg file extension. because developers distribute locally running SWF files by installing the application, you can have the installation application add a configuration file to the global Flash Player trust directory, granting full access to the files to be distributed. The installation application must be run by a user with administrative rights. Unlike the MMS.cfg file, the global Flash Player Trust directory is included to enable the installation application to grant trust permissions. Both managing users and installing applications can specify trusted local applications using the Global Flash Player Trust directory. after reading this article, it turns out that the project in Flex actually adds the output file from the project to the local trust sandbox. The CFG documentation for Flex was also found in the local directory specified, which does include the output folders for each project. So I also tried to add the directory where the DVF was in to the local trust sandbox. The entire folder path string is written to a text file based on the CFG file format described in the article, and then saved as a CFG file. Put it in the system/Macromed/Flash/FlashPlayerTrust. Then run the DVF again, the error message is gone, and the problem is resolved. in retrospect, Flash Player is really getting stricter with security. The current version is so strict even for local runs (the version I used before was 9.0, so long as You set allowScriptAccess to always in HTML). Only a thorough understanding of Flash Player's security mechanisms can help us solve the problem better. However, I use above is the management of user control method to achieve, so it is the highest level of configuration, there may be relatively large security risks, you can also try to use the ordinary user control method to add trust. The article write here, hope to be helpful to everybody.
