What is Software? | What is Education? | What is Technology? | What is Research? | What is Wi-Fi? | What is Communication? | What is Customer Service?

Free SEO Tutorials & Help

Tutorials:   Adobe Flash   Adobe Photoshop   CorelDRAW   SEO  

Site Map

Website Development | Cable & Broadband Magazine | Solutions for Higher Education | Auction Anything Online

 

Adobe Flash Help & Tutorials

 Back to Topics

 

What is Security in Flash

Understanding Security

About compatibility with previous Flash Player security models

About local file security and Flash Player

Understanding local security sandboxes

About Flash Player security settings

About local file security and projector files

About troubleshooting legacy SWF files

Fixing legacy content deployed on local computers

Publishing files for local deployment

Testing content locally with Flash 8 local file security restrictions

Specifying trusted files using the Settings Manager

Creating configuration files for Flash development

About the sandboxType property

About local-with-file-system restrictions

About domains, cross-domain security, and SWF files

Domain name rules for settings and local data

Cross-domain and subdomain access between SWF files

Allowing data access between cross-domain SWF files

Server-side policy files for permitting access to data

Allowing cross-domain data loading

About custom policy file locations

About XMLSocket policy files

HTTP to HTTPS protocol access between SWF files

Allowing HTTP to HTTPS protocol access between SWF files

Understanding Security

TOP

In Macromedia Flash Basic 8 and Macromedia Flash Professional 8, you can use ActionScript to load data from external sources into a SWF file or send data to a server. When you load data into a SWF file, you need to understand and accommodate the Flash 8 security model. When you open a SWF file on your hard disk, you might need to make special configurations so you can test your file locally.

 

About compatibility with previous Flash Player security models

TOP

As a result of the security feature changes in Flash Player 7, content that runs as expected in Flash Player 6 or earlier might not run as expected in later versions of Flash Player. For example, in Flash Player 6, a SWF file that resides in www.macromedia.com could read data on a server located at data.macromedia.com; that is, Flash Player 6 allowed a SWF file from one domain to load data from a similar domain.

In Flash Player 7 and later, if a version 6 (or earlier) SWF file attempts to load data from a server that resides in another domain, and that server doesn't provide a policy file that allows reading from that SWF file's domain, the Macromedia Flash Player Settings dialog box appears. The dialog box asks the user to allow or deny the cross-domain data access.

If the user clicks Allow, the SWF file can access the requested data; if the user clicks Deny, the SWF file cannot access the requested data.

To prevent this dialog box from appearing, you should create a security policy file on the server providing the data. For more information, see Allowing cross-domain data loading.

Flash Player 7 and later do not allow cross-domain access without a security policy file.

Flash Player 8 changed the way it handles System.security.allowDomain. A Flash 8 SWF file that calls System.security.allowDomain with any argument, or any other SWF file that uses the wildcard (*) value, permits access only to itself. There is now support for a wildcard (*) value, for example: System.security.allowDomain("*") and

System.security.allowInsecureDomain("*"). If a SWF file of version 7 or earlier calls System.security.allowDomain or System.security.allowInsecureDomain with an argument other than wildcard (*), this will affect all SWF files of version 7 or lower in the calling SWF file's domain, as it did in Flash Player 7. However, this kind of call does not affect any Flash Player 8 (or later)

SWF files in the calling SWF file's domain. This helps minimize legacy content breaking in Flash Player.

Flash Player 8 does not allow local SWF files to communicate with the Internet without a specific configuration on your computer. Suppose you have legacy content that was published before these restrictions were in effect. If that content tries to communicate with the network or local file system, or both, Flash Player 8 stops the operation, and you must explicitly provide permission for the application to work properly. For more information, see About local file security and Flash Player
 

About local file security and Flash Player

TOP

Flash Player 8 has made enhancements to the security model, in which Flash applications and SWF files on a local computer are not allowed to communicate with both the Internet and the local file system by default. A local SWF file is a SWF file that is locally installed on a user's computer, not served from a website, and does not include projector (EXE) files.

NOTE : The restrictions that are discussed in this section do not affect SWF files that are on the Internet.

When you create a FLA file, you can indicate whether a SWF file is allowed to communicate with a network or with a local file system. In previous versions of Flash Player, local SWF files could interact with other SWF files and load data from any remote or local location. In Flash Player 8, a SWF file cannot make connections to the local file system and the Internet. This is a safety change, so a SWF file cannot read files on your hard disk and then send the contents of those files across the Internet.

This security restriction affects all locally deployed content, whether it is legacy content (a FLA file created in an earlier version of Flash) or created in Flash 8. Suppose you deploy a Flash application, using Flash MX 2004 or earlier, that runs locally and also accesses the Internet. In Flash Player 8, this application now prompts the user for permission to communicate with the Internet.

When you test a file on your hard disk, there are a series of steps to determine whether the file is a local trusted document or a potentially untrusted document. If you create the file in the Flash authoring environment (for example, when you select Control > Test Movie), your file is trusted because it is in a test environment.

In Flash Player 7 and earlier, local SWF files had permissions to read from both a local file system and the network (such as the Internet). In Flash Player 8, local SWF files can have the following levels of permission:

Access the local file system only (default) A local SWF file can read from the local file system and universal naming convention (UNC) network paths but cannot communicate with the Internet. For more information on local file access SWF files, see Access local files only (default).

Access the network only  A local SWF file can access the network (such as the Internet) but not the local file system where it is installed. For more information on network-only SWF files, see Access network only.

Access to the local file system and the network A local SWF file can read from the local file system where it is installed, read and write to and from servers, and can cross-script other SWF files on either the network or the local file system. These files are trusted, and behave like they did in Flash Player 7. For more information on local and network access SWF files, see Access file system and network.

 

Understanding local security sandboxes

TOP

There are several different security sandboxes in the Flash Player. Each one determines how a SWF file can interact with the local file system, the network, or both the local file system and network at the same time. Restricting how a file can interact with the local file system, or the network helps keep your computer and files safe. Understanding security sandboxes helps you develop and test Flash applications on your computer without encountering unexpected errors.

Local-with-file-system

For security purposes, Flash Player 8 places all local SWF files, including all legacy local SWF files, in the local-with-file-system sandbox, by default (unless some other setting is made). For some legacy (earlier than Flash Player 8) SWF files, operations could be affected by enforcing restrictions on their access (no outside network access), but this provides the most secure default for the users' protection.

From this sandbox, SWF files may read from files on local file systems or UNC network paths (by using the XML.load() method, for example), but they may not communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared.

Local-with-networking

When local SWF files are assigned to the local-with-networking sandbox, they forfeit their local file system access. In return, the SWF files are allowed to access the network. However, a local-with-networking SWF file still is not allowed to read any network-derived data unless permissions are present for that action. Therefore, a local-with-networking SWF file has no local access, yet it has the ability to transmit data over the network and can read network data from those sites that designate site-specific access permissions.

Local-trusted

SWF files assigned to the local-trusted sandbox can interact with any other SWF files, and load data from anywhere (remote or local).
 

About Flash Player security settings

TOP

Macromedia has designed Flash Player to provide security settings that do not require you to explicitly allow or deny access in most situations. You might occasionally encounter legacy Flash content that was created using older security rules for Flash Player 7 or earlier. In these cases, Flash Player lets you allow the content to work as the developer intended, using the older security rules; or, you can choose to enforce the newer, stricter rules. The latter choice ensures that you only view or play content that meets the most recent standards of security, but it may sometimes prevent older Flash content from working properly.

All users who view SWF files (including non-Flash developers) can set permissions globally through the Global Security Settings panel in Flash Player's Settings Manager (shown in the following figure).

When older content runs in a newer version of the player, and Flash Player needs you to make a decision about enforcing newer rules or not, you may see one of the following pop-up dialog boxes. These dialog boxes ask your permission before allowing the older Flash content to communicate with other locations on the Internet:

  • A dialog box might appear alerting you that the Flash content you are using is trying to use older security rules to access information from a site outside its own domain, and that information might be shared between two sites. Flash Player asks if you want to allow or deny such access.

    In addition to responding to the dialog box, you can use the Global Security Settings panel to specify whether Flash Player should always ask for your permission, through the dialog box, before allowing access; always deny access, without asking first; or always allow access to other sites or domains without asking your permission.

  • (Flash Player 8 only) A dialog box might appear alerting you that a SWF file is trying to communicate with the Internet. Flash Player 8 doesn't let local Flash content communicate with the Internet, by default.



    Click Settings to access the Global Security Settings panel, where you can specify that certain Flash applications on your computer may communicate with the Internet.

To change your security settings or learn more about your options, you use the Global Security Settings panel. Use this panel to reset the privacy settings in Macromedia Flash Player:

  • If you select Always Deny and then confirm your selection, any website that tries to use your camera or microphone is denied access. You are not asked again whether a website can use your camera or microphone. This action applies both to websites you have already visited and to those you haven't yet visited.

  • If you select Always Ask and then confirm your selection, any website that tries to use your camera or microphone must ask your permission. This action applies both to websites you have already visited and to those you haven't yet visited.

If you previously selected Remember in the Privacy Settings panel (see the following figure) to permanently allow or deny access for one or more websites, selecting Always Ask or Always Deny has the effect of deselecting Remember for all those websites. In other words, the selection you make here overrides any previous selections you may have made in the Privacy Settings panel, shown in the following figure.



After you select either Always Ask or Always Deny (or instead of doing so), you can specify privacy settings for individual websites that you have already visited. For example, you might select Always Deny here, then use the Website Privacy Settings panel and select Always Allow for individual websites that you know and trust.

For locally deployed content and local data, users have another option: They can specify which SWF files may access the Internet using the Global Security Settings panel. For more information on specifying settings in the Global Security Settings panel, see Specifying trusted files using the Settings Manager. For more information on the Global Security Settings panel, see www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04a.html.

NOTE : The selections users make in the Global Security Settings panel override any decisions made in the security pop-up dialog box.

 

About local file security and projector files 

TOP

Projector files and the SWF files contained within them or loaded into the projector at runtime are not affected by local file security restrictions, because the end user must run the executable to use the SWF file. There are no changes to security and projector files in Flash Player 8; it has the same level of access and security as earlier versions of Flash Player.

Remember that users are often cautious about executing projector files. A projector file is an executable EXE or Macintosh application, and users should be careful about running such files on their computers. If you distribute an application using projector files, some users might not install it.

In addition, a projector file embeds a specific version of Flash Player inside the projector, which might be older than the latest version of Flash Player available for download from the Macromedia website. The Flash Player that's embedded within the projector file might be a legacy version if the projector was created with an older version of Flash, or an edition of Flash Player was released after the current version of the Flash authoring tool. For these reasons, you should distribute applications using SWF files when possible.

 

About troubleshooting legacy SWF files 

TOP

Some legacy FLA and SWF files (created with Flash MX 2004 and earlier) might not work when you test or deploy them locally (on a hard disk) because of security changes in Flash 8. This might happen when a SWF file tries to access websites outside its domain, and, in this case, you need to implement a cross-domain policy file.

You might have FLA or SWF files created in Flash MX 2004 or earlier that have been distributed to users who do not use the Flash 8 authoring tool but have upgraded to Flash Player 8. If your locally tested or deployed legacy content (an old SWF file on a user's hard disk) breaks because it tries to communicate with the Internet when playing in Flash Player 8, you must rely on users to explicitly trust your content in order for it to play properly (by clicking a button in a dialog box).

To learn how to fix legacy content for playback on a local computer, see Fixing legacy content deployed on local computers.
 

Fixing legacy content deployed on local computers

TOP

If you published SWF files for Flash Player 7 or earlier that are deployed on local computers and communicate with the Internet, users must explicitly allow Internet communication. Users can stop content from breaking by adding the location of the SWF file on their local computer to the trusted sandbox in the Settings Manager.

To fix SWF files for local playback, use any of the following options:

Redeploy Run the Local Content Updater. The Local Content Updater reconfigures your SWF file to make it compatible with the Flash Player 8 security model. You reconfigure the local SWF file so it can either access only the network or only the local file system. For more information, and to download the Local Content Updater,

Republish and redeploy  Republish the file with Flash Basic 8 or Flash Professional 8. The authoring tool requires you to specify in the Publish Settings dialog box whether a local SWF file can access the network or the local file system--but not both. If you specify that a local SWF file can access the network, you also must enable permissions for that SWF file (and all local SWF files) in the SWF, HTML, data, and/or server files that it accesses. For more information, see Publishing files for local deployment.

Deploy new content  Use a configuration (.cfg) file in the #Security/FlashPlayerTrust folder. You can use this file to set network and local access permissions. For more information, see Creating configuration files for Flash development.

NOTE : Any of these options require that you either republish or redeploy your SWF file.

 

Publishing files for local deployment

TOP

 
You might send your Flash 8 FLA or SWF files to a user to test or approve and need the application to access the Internet. If your document plays back on a local system but accesses files on the Internet (for example, loading XML or sending variables), your user might need a configuration file for the content to function properly, or you might need to set up the FLA file so the

SWF file that you publish can access the network. Alternatively, you can set up a configuration file inside the FlashPlayerTrust directory. For more information on setting up configuration files, see Creating configuration files for Flash development.

Use Flash Basic 8 or Flash Professional 8 to create content for local deployment that works with Flash Player 8 local file security. In Flash 8 publish settings, you must specify whether local content can access the network or access the local file system, but not both.

You can set permission levels for a FLA file in the Publish Settings dialog box. These permission levels affect the local playback of the FLA file, when it plays locally on a hard disk.

NOTE : If you specify network access for a local file, you must also enable permissions in the SWF, HTML, data, and server files that are accessed by the local SWF file.

Network SWF files  SWF files that download from a network (such as an online server) are placed in a separate sandbox that corresponds to their unique website origin domains. Local SWF files that specify they have network access are placed in the local-with-networking sandbox. By default, these files can read data from only the same site from which they originated. Exact-domain matching applies to these files. Network SWF files can access data from other domains if they have the proper permissions. For more information on network SWF files, see Access network only.

Local SWF files  SWF files that operate with local file systems or UNC network paths are placed into one of three sandboxes in Flash Player 8. By default, local SWF files are placed in the local-with-file-system sandbox. Local SWF files that are registered as trusted (using a configuration file) are placed in the local-trusted sandbox. For information on the three sandboxes, see Access local files only (default).

For more information on the security sandbox, see Understanding local security sandboxes.

The first two permission levels are set in the Flash authoring environment, and the third is set using the Global Security Settings panel or the FlashAuthor.cfg file. The following example shows what options are available when you publish a file for testing on your local hard disk.

To publish a document with a specified permission level:

  1. Open the FLA file for which you want to specify a permission level.
  2. Select File > Publish Settings > Flash.
  3. Find the Local Playback Security dialog box, and select one of the following options from the pop-up menu:
    • Access local files only (See Access local files only (default))
    • Access network only (See Access network only)
  4. Click OK to continue authoring the FLA file, or click Publish to create the SWF file.

Access local files only (default)

To set this permission level, select Publish Settings > Flash, and then select Access Local Files Only from the Local Playback Security pop-up menu. This permission level lets a local SWF file access only the local file system where the SWF file is running. The SWF file can read from known files on the local disk without any restrictions. However, the following restrictions apply to the application accessing the network:

  • The SWF file cannot access the network in any way. The SWF file cannot cross-script network SWF files, or be cross-scripted by network SWF files.
  • The SWF file cannot communicate with local SWF files that have permission to access the network only, and the SWF file cannot communicate with HTML pages. However, in some cases communication is allowed, such as if the HTML is trusted and allowScriptAccess is set to always or if allowScriptAccess is not set and the SWF file is Flash Player 7 or earlier.

Access network only

To set this permission level, select Publish Settings > Flash, and then select Access Network Only from the Local Playback Security pop-up menu. Local SWF files with network access can read from a server if the server contains a cross-domain policy file with <allow-access-from-domain= "*">. Local SWF files with network access may cross-script other SWF files if the other SWF files, which are being accessed, contain System.security.allowDomain("*"). A local SWF file with network access can be cross-scripted by network SWF files if the local SWF file contains allowDomain("*"). The SWF file can never read from local files. In some cases, the type of SWF file affects the access. For information, see allowDomain (security.allowDomain method) in the ActionScript 2.0 Language Reference.

The wildcard (*) value indicates that all domains, including local hosts, are allowed access. Be certain you want to provide this broad level of access before using the wildcard argument.
Without any of these permissions, local SWF files with network access can communicate only with other local SWF files that have network access, and they can send data to servers (using XML.send(), for example). In some cases, access is allowed if the HTML file is trusted.

Access file system and network 

This level is the highest level of permission. A local SWF file that has these permissions is a trusted local SWF file. Trusted local SWF files can read from other local SWF files, interact with any server, and write ActionScript for other SWF files or HTML files that have not explicitly forbidden the file permission (for example, with allowScriptAccess="none"). This level of permission can be granted by the user or Flash developer in the following ways:

  • Using the Global Security Settings panel in the Settings Manager.
  • Using a global configuration file.

A configuration file can be installed with the SWF file, created by a Flash developer, or added by an administrator (for all users or the current user) or any Flash developer (for the current user).

 

Testing content locally with Flash 8 local file security restrictions

TOP

As a Flash developer, you frequently test Flash applications locally, so you might see a dialog box prompt when a local Flash application tries to communicate with the Internet. You might see this dialog box when you test a SWF file in Flash Player if the SWF file does not have network access. For more information on publishing SWF files with specified permission levels, see Publishing files for local deployment. Publishing a SWF file with one of these options means you can communicate with the network or the local file system.

At times, you might need to communicate with the local file system and the network when you are testing a document. Because the new security model might interrupt your workflow when you are authoring Flash applications, you can use the Global Security Settings panel in Flash Player's Settings Manager to specify which Flash applications on your computer can always communicate with both the Internet and the local file system. Or, you can modify the configuration file to specify trusted directories on your hard disk.

 

Specifying trusted files using the Settings Manager

TOP

You can specify what Flash content on your computer may always use the older security rules by adding the location of the content to the Global Security Settings panel in the Flash Player Settings Manager. After you add a location on your computer to the Security panel, content in that location is trusted. Flash Player won't ask you for permission and is always allowed to use the older security rules, even if Always Deny is selected in the Security panel. The Always Trust Files in These Locations list overrides the options in the Settings panel. That is, if you select to always deny local and web content the right to use the older security rules, the local files in your trusted list are always allowed to use the older rules.

The Always trust files list at the bottom of the panel applies specifically to Flash content that you have downloaded to your computer, not content that you use while visiting a website.

The following example shows how to specify that a local SWF file can communicate with the Internet. When you test a file in a browser locally (File > Publish Preview > HTML), a security dialog box might appear. If you click Settings, the Settings Manager Global Security Settings panel appears


 

To specify that a local SWF file can communicate with the Internet and local file system:

  1. In the Global Security Settings panel, click the pop-up menu and select Add Location.

    The Add Location box opens.

    If you arrived at the Settings Manager by clicking the Settings button in a dialog box, the Add Location box contains a path that is similar to C:\directoryname\filename.swf or /Users/directoryname/filename.swf; this path tells you which file tried to communicate with the Internet and was stopped by Flash Player security. If the path contains the content that you want to let communicate with the Internet, copy and paste the path into the Trust This Location box. Or, click one of the Browse buttons and find the content yourself.

    You can add an individual file or an entire directory. If you add an entire directory, all the files and subdirectories in that directory are trusted. Some Flash content consists of multiple related files, and you might need to trust the entire directory where all the related files are located. In general, avoid trusting top-level directories.

  2. Click Confirm.

The location is added to the Security Settings panel. Locations listed are always allowed to use the older security rules, even if the Always Deny or Always Ask options at the top of the Security panel are selected.

After you add trusted locations, you must restart the local Flash content by either refreshing the browser or restarting the player.

If you click Always Allow, it only applies that setting to always allow legacy content (Flash Player 7 and earlier). The setting does not "always allow" Flash Player 8 content. It is recommended that you specify the Flash applications and directories on your computer that can communicate with both the Internet and the local file system.
 

Creating configuration files for Flash development

TOP

The Flash 8 authoring tool sets a flag on your hard disk to identify you as a developer to direct you to a specific developer-oriented version of the Global Security Settings panel instead of a user-oriented Global Security Settings panel. The flag is in the FlashAuthor.cfg file on your hard disk, which installs automatically when the Flash Basic 8 and Flash Professional 8 authoring tool installs.

The FlashAuthor.cfg file is located in the following approximate directories:

Windows  boot disk\Documents and Settings\<UserName>\Application Data\Macromedia\Flash Player\#Security

Macintosh /Users/<UserName>/Library/Preferences/Macromedia/Flash Player/#Security/

By default, this file is set to LocalSecurityPrompt=Author, which means the warnings you see on your computer treat you as a Flash developer as opposed to a user without the authoring tool installed.

You can test your local applications as an end user and see the warning dialog boxes that an end user would encounter. To do so, open FlashAuthor.cfg in a text editor, and change the LocalSecurityPrompt in the FlashAuthor.cfg file to match the following:

LocalSecurityPrompt=User

You might want to provide a FlashAuthor.cfg file, with LocalSecurityPrompt set to Author, to other developers in your design or development process or to users who test Flash applications on their local hard disk and do not have the Flash 8 authoring tool installed. This helps you mimic the end user's experience with your locally deployed content.

NOTE : If the FlashAuthor.cfg file is deleted, the file is recreated when you launch the Flash 8 authoring tool.

In the #Security directory on your hard disk, you can create a FlashPlayerTrust directory where you can store unique configuration files. Inside these files, you can specify directories or applications to trust on your hard disk. This directory does not require administrative access, so users without administrative permissions can set permissions for SWF files and test applications.

If you do not specify a directory, your content might not function as intended. Configuration files inside a FlashPlayerTrust directory contain directory paths. The file can contain a list of several directories, and you can append new paths to the file. Flash Player expects one path per line in configuration files. Any line that begins with a # punctuator (with no leading space before it) is treated as a comment.

To create a configuration file to trust a directory:

  1. Locate the #Security folder on your hard disk.

  2. Create a folder called FlashPlayerTrust inside the #Security folder.

  3. Create a new file in the FlashPlayerTrust directory using a text editor, and save it as myTrustFiles.cfg.

    You can use any unique name for your configuration file.

  4. Locate the directory where you test Flash applications.

  5. Type or paste each directory path (any directory path on your hard disk) on a new line in the file. You can paste multiple directory paths on separate lines. When you finish, your file looks similar to the following example:

    C:\Documents and Settings\<yourname>\My Documents\files\

    C:\Documents and Settings\<yourname>\My Documents\testapps\

  6. Save your changes to myTrustFiles.cfg.

  7. Test a document that accesses local and network files from the directory you added to the file.

Flash applications saved in this directory can now access local files and the network.

There can be numerous directory paths saved in each configuration file, and numerous *.cfg files saved in the FlashPlayerTrust directory.

If you create applications that install on an end user's hard disk, you might need to create a configuration file in FlashPlayerTrust to specify a trusted directory for your application. You can create configuration files inside the FlashPlayerTrust directory that specify the location of the trusted application. See the pervious procedure for information on this directory and creating configuration files.

NOTE : An installer is run by a user with administrative permission on a computer.

You should develop a unique naming scheme to avoid conflicts with other applications that might install files in this directory. For example, you might want to use your unique company and software name in the filename to avoid conflicts.

TIP : If you do not want to use configuration files, you could publish your Flash applications to a separate, testing server instead of providing clients or other developers SWF files to run on their local hard disks.

 

About the sandboxType property

TOP

Flash Player 8's System.security.sandboxType property returns the type of security sandbox in which the calling SWF file is operating.

The sandboxType property has one of the four following values:

remote The SWF file is hosted on the Internet and operates under domain-based sandbox rules.

localTrusted The SWF file is a local file that has been trusted by the user, using either the Global Security Settings Manager or a FlashPlayerTrust configuration file. The SWF file can both read from local data sources and communicate with the network (such as the Internet).

localWithFile The SWF file is a local file that has not been trusted by the user, and was not published with a networking designation. The SWF file can read from local data sources but cannot communicate with the network (such as the Internet).

localWithNetwork The SWF file is a local file that has not been trusted by the user, and was published with Access Network Only selected in the Publish Settings dialog box (Flash tab). The SWF file can communicate with the network but cannot read from local data sources.

You can check the sandboxType property from any SWF file, although a value is returned only in files published for Flash Player 8. This means that when you publish for Flash Player 7 or earlier, you do not know whether the sandboxType property is supported at runtime. If the property isn't supported at runtime, the value is undefined, which occurs when the Flash Player version (indicated by the System.capabilities.version property) is less than 8. If the value is undefined, you can determine the sandbox type according to whether your SWF file's URL is a local file or not. If the SWF file is a local file, Flash Player classifies your SWF as localTrusted (which is how all local content was treated prior to Flash Player 8); otherwise Flash Player classifies the SWF file as remote.

 

About local-with-file-system restrictions

TOP

A local-with-file-system file has not been registered using the configuration file inside the FlashPlayerTrust directory, the Global Security Settings panel in the Settings Manager, or has not been granted network permission in the Publish Settings dialog box in the Flash authoring environment.

NOTE : For information on security sandboxes, see Understanding local security sandboxes.

These files include legacy content that plays in Flash Player 8. If you are developing content in Flash 8, or you have content that falls into one of the following categories, you (or your users) should register the file as trusted. For information on registering a file as trusted, see Specifying trusted files using the Settings Manager. For information on granting permission for local fileplayback using configuration files, see Creating configuration files for Flash development.

Local-with-file-system SWF files have the following restrictions:

  • Cannot access the network, which includes the following:

  • Loading other SWF files from the network (except using non-Internet UNC paths)

  • Sending HTTP requests

  • Making connections using XMLSocket, Flash Remoting, or NetConnection

  • Calling getURL() except if you use getURL("file:...") or getURL("mailto:...")

  • Can interact with other local-with-file-system files, but includes restrictions to the following:

    • Cross-scripting (such as ActionScript access to objects in other SWF files).

    • Calling System.security.allowDomain

    • Using LocalConnection as sender or listener and regardless of LocalConnection.allowDomain handlers.

  • NOTE : Local-with-file-system SWF files can interact with other local-with-file-system, non-network SWF files. However, they cannot interact with local-with-network SWF files.

  • Local-with-file-system SWF files have read access to known files on the local file system. For example, you can use XML.load() in a local-with-file-system SWF file as long as you load from the local file system and not the Internet.

  • Local-with-file-system SWF files cannot communicate with HTML pages, which includes the following:

  • Inbound scripting (such as ExternalInterface API, ActiveX, LiveConnect, and XPConnect)

  • Outbound scripting (such as custom fscommand calls, and getURL("javascript:..."))

  • NOTE : An exception to this is if the HTML page is trusted.

About domains, cross-domain security, and SWF files

TOP

By default, Flash Player 7 and later versions prevent a SWF file served from one domain from reading data, objects, or variables from SWF files that are served from different domains. In addition, content that is loaded through nonsecure (non-HTTPS) protocols cannot read content loaded through a secure (HTTPS) protocol, even when both are in exactly the same domain. For example, a SWF file located at http://www.macromedia.com/main.swf cannot load data from https://www.macromedia.com/data.txt without explicit permission; neither can a SWF file served from one domain load data (using loadVars(), for example) from another domain.

Identical numeric IP addresses are compatible. However, a domain name is not compatible with an IP address, even if the domain name resolves to the same IP address.

The following table shows examples of compatible domains:

www.macromedia.com

www.macromedia.com

data.macromedia.com

data.macromedia.com

65.57.83.12

65.57.83.12

The following table shows examples of incompatible domains:

www.macromedia.com

data.macromedia.com

macromedia.com

www.macromedia.com

www.macromedia.com

macromedia.com

65.57.83.12

www.macromedia.com (even if this domain resolves to 65.57.83.12)

www.macromedia.com

65.57.83.12 (even if www.macromedia.com resolves to this IP address)

Flash Player 8 does not allow local SWF files to communicate with the Internet without a proper configuration. For information on setting up a configuration file to test content locally, see Creating configuration files for Flash development.
 

Domain name rules for settings and local data

TOP

In Flash Player 6, superdomain matching rules are used by default when accessing local settings (such as camera or microphone access permissions) or locally persistent data (shared objects). That is, the settings and data for SWF files hosted at here.xyz.com, there.xyz.com, and xyz.com are shared and are all stored at xyz.com.

In Flash Player 7, exact-domain matching rules are used by default. That is, the settings and data for a file hosted at here.xyz.com are stored at here.xyz.com, the settings and data for a file hosted at there.xyz.com are stored at there.xyz.com, and so on. System.exactSettings lets you specify which rules to use. This property is supported for files published for Flash Player 6 or later. For files published for Flash Player 6, the default value is false, which means superdomain matching rules are used. For files published for Flash Player 7 or 8, the default value is true, which means exact-domain matching rules are used. If you use settings or persistent local data and want to publish a Flash Player 6 SWF file for Flash Player 7 or 8, you might need to set this value to false in the ported file. For more information,

 

Cross-domain and subdomain access between SWF files

TOP

When you develop a series of SWF files that communicate with each other online--for example, when using loadMovie(), MovieClip.loadMovie(), MovieClipLoader.LoadClip(), or Local Connection objects--you might host the SWF files in different domains or in different subdomains of a single superdomain.

In files published for Flash Player 5 or earlier, there were no restrictions on cross-domain or subdomain access.

In files published for Flash Player 6, you could use the LocalConnection.allowDomain handler or System.security.allowDomain() method to specify permitted cross-domain access (for example, to let a file at someSite.com be accessed by a file at someOtherSite.com), and no command was needed to permit subdomain access (for example, a file at www.someSite.com could be accessed by a file at store.someSite.com).

Files published for Flash Player 7 implement access between SWF files differently from earlier versions in two ways. First, Flash Player 7 implements exact-domain matching rules instead of superdomain matching rules. Therefore, the file being accessed (even if it is published for a Flash Player version earlier than Flash Player 7) must explicitly permit cross-domain or subdomain access; this topic is discussed in this section. Second, a file hosted at a site using a secure protocol (HTTPS) must explicitly permit access from a file hosted at a site using an insecure protocol (HTTP or FTP); this topic is discussed in the next section (see HTTP to HTTPS protocol access between SWF files).

You usually call System.security.allowDomain in your applications. However, when the LocalConnection receiver is an HTTPS SWF file and the sender is not, allowInsecureDomain is called instead.

The following issue affects only SWF files published for Flash Player 7. When the receiver is HTTPS, and the sender is a local SWF file, allowDomain() is called, even though allowInsecureDomain() should be called. However, in Flash Player 8, when an HTTPS LocalConnection receiver is Flash Player 8, and the sender is a local file, allowInsecureDomain() is called.

Files that run in Flash Player 8 are subject to changes from how they run in Flash Player 7. Calling System.security.allowDomain permits cross-scripting operations only where the SWF file being accessed is the one that called System.security.allowDomain. In other words, a SWF file that calls System.security.allowDomain now permits access only to itself. In previous versions, calling System.security.allowDomain permitted cross-scripting operations where the SWF file being accessed could be any SWF file in the same domain as the one that called

System.security.allowDomain. Doing so opened up the entire domain of the calling SWF file.

Support has been added for the wildcard (*) value to System.security.allowDomain("*") and System.security.allowInsecureDomain("*"). The wildcard (*) value permits cross-scripting operations where the accessing file is any file and can be loaded from any location (such as global permission). Wildcard permissions can be useful, but they must adhere to the new local file security rules in Flash Player 8. Specifically, local files do not come from a domain, so the wildcard value must be used. However, use caution when using the wildcard value because any domain has access to your file. For more information, see allowInsecureDomain (security.allowInsecureDomain method).

You might encounter a situation when you load a child SWF file from a different domain than the one calling it. You might want to allow that file to script the parent SWF file, but you don't know the final domain from which the child SWF file will come. This situation can happen, for example, when you use load-balancing redirects or third-party servers. In this situation, you can use the MovieClip._url property as an argument to this method. For example, if you load a SWF file into my_mc, you can call System.security.allowDomain(my_mc._url). If you do this, you must wait until the SWF file in my_mc begins loading because the _url property does not have its final, correct value yet. To determine when a child SWF file has started to load, useMovieClipLoader.onLoadStart.

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) from the child SWF file. You don't have to wait for the parent SWF file to load because it is loaded before the child file loads.

NOTE : 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

Cross-domain access between SWF files (allowDomain() is needed)

Subdomain access between SWF files

5 or earlier

No restrictions

No restrictions

6

Superdomain matching: allowDomain() is needed if superdomains do not match.

No restrictions

7 and later

Exact domain matching

Explicit permission for HTTPS-hosted files to access HTTP- or FTP-hosted files

Exact domain matching

Explicit permission for HTTPS-hosted files to access HTTP- or FTP-hosted files

NOTE : You need System.security.allowInsecureDomain in Flash Player 7 and later if you are 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() in deployed SWF files.

Because Flash Player 7 and later versions implement exact-domain matching rules instead of superdomain matching rules, you might have to modify existing scripts if you want to read them from files that are published for Flash Player 7 or 8. (You can still publish the modified files for Flash Player 6.) If you used any LocalConnection.allowDomain() or

System.security.allowDomain() statements in your files and specified superdomain sites to permit, you must change your parameters to specify exact domains instead. The following example shows changes you might have to make if you have Flash Player 6 code:

// Flash Player 6 commands in a SWF file at www.anyOldSite.com

// to allow access by SWF files that are hosted at www.someSite.com

// or at store.someSite.com

System.security.allowDomain("someSite.com");

my_lc.allowDomain = function(sendingDomain) {

return(sendingDomain=="someSite.com");

}

// Corresponding commands to allow access by SWF files

// that are published for Flash Player 7 or later

System.security.allowDomain("www.someSite.com", "store.someSite.com");

my_lc.allowDomain = function(sendingDomain) {

return(sendingDomain=="www.someSite.com" ||

sendingDomain=="store.someSite.com");

}

You might also have to add statements such as these to your files if you aren't currently using them. For example, if your SWF file is hosted at www.someSite.com and you want to allow access by a SWF file published for Flash Player 7 or later at store.someSite.com, you must add statements such as the following example to the file at www.someSite.com (you can still publish the file at www.someSite.com for Flash Player 6):

System.security.allowDomain("store.someSite.com");

my_lc.allowDomain = function(sendingDomain) {

return(sendingDomain=="store.someSite.com");

}

In addition, consider that if a Flash Player 6 application running in Flash Player 7 tries to access data outside its exact domain, Flash Player 7 and later domain-matching rules are enforced and the user is prompted to allow or deny access.

To summarize, you might have to modify your files to add or change allowDomain statements if you publish files for Flash Player 7 or later that meet the following conditions:

  • You implemented cross-SWF file scripting (see Allowing data access between cross-domain SWF files).

  • The called SWF file (of any version) is not hosted at a site using a secure protocol (HTTPS), or the calling and called SWF files are both hosted at HTTPS sites. (If only the called SWF file is HTTPS, see HTTP to HTTPS protocol access between SWF files.)

  • The SWF files are not in the same domain (for example, one file is at www.domain.com and one is at store.domain.com).

You must make the following changes:

  • If the called SWF file is published for Flash Player 7 or later, include System.security.allowDomain or LocalConnection.allowDomain in the called SWF file, using exact domain-name matching.

  • If the called SWF file is published for Flash Player 6, modify the called file to add or change a System.security.allowDomain or LocalConnection.allowDomain statement, using exact domain-name matching, as shown in the code examples earlier in this section. You can publish the modified file for either Flash Player 6 or 7.

  • If the called SWF file is published for Flash Player 5 or earlier, port the called file to Flash Player 6 or 7 and add a System.security.allowDomain statement, using exact domain-name matching, as shown in the code examples earlier in this section. (LocalConnection objects aren't supported in Flash Player 5 or earlier.)

 

Allowing data access between cross-domain SWF files

TOP

For two SWF files to access each other's data (variables and objects), the two files must originate from the same domain. By default, in Flash Player 7 and later, the two domains must match exactly for the two files to share data. However, a SWF file can grant access to SWF files served from specific domains by calling LocalConnection.allowDomain or

System.security.allowDomain().

System.security.allowDomain() lets SWF files and HTML files in specified domains access objects and variables in the SWF file that contains the allowDomain() call.

If two SWF files are served from the same domain--for example, http://mysite.com/movieA.swf and http://mysite.com/movieB.swf--then movieA.swf can examine and modify variables, objects, properties, methods, and so on in movieB.swf, and movieB can do the same for movieA. This is called cross-movie scripting, or cross-scripting.

If two SWF files are served from different domains--for example, http://mysite.com/movieA.swf and http://othersite.com/movieB.swf--then, by default, Flash Player does not allow movieA.swf to script movieB.swf, nor movieB to script movieA. If you call System.security.allowDomain("mysite.com"), movieB.swf gives movieA.swf permission to script movieB.swf. A SWF file gives SWF files from other domains permission to script it by calling System.security.allowDomain(). This is called cross-domain scripting.

For further information on System.security.allowDomain(), cross-scripting, and cross-domain scripting, see allowDomain (security.allowDomain method) in the ActionScript 2.0 Language Reference.

For example, suppose main.swf is served from www.macromedia.com. That SWF file then loads another SWF file (data.swf) from data.macromedia.com into a movie clip instance that's created dynamically using createEmptyMovieClip().

// In macromedia.swf

this.createEmptyMovieClip("target_mc", this.getNextHighestDepth());

target_mc.loadMovie("http://data.macromedia.com/data.swf");

Suppose that data.swf defines a method named getData() on its main Timeline. By default, main.swf cannot call the getData() method defined in data.swf after that file has loaded because the two SWF files do not reside in the same domain. For example, the following method call in main.swf, after data.swf has loaded, fails:

// In macromedia.swf, after data.swf has loaded:

target_mc.getData(); // This method call will fail

However, data.swf can grant access to SWF files served from www.macromedia.com by using the LocalConnection.allowDomain handler and the System.security.allowDomain() method, depending on the type of access required. The following code, added to data.swf, allows a SWF file served from www.macromedia.com to access its variables and methods:

// Within data.swf

this._lockroot = true;

System.security.allowDomain("www.macromedia.com");

var my_lc:LocalConnection = new LocalConnection();

my_lc.allowDomain = function(sendingDomain:String):Boolean {

return (sendingDomain == "www.macromedia.com");

};

function getData():Void {

var timestamp:Date = new Date();

output_txt.text += "data.swf:" + timestamp.toString() + "\n\n";

}

output_txt.text = "**INIT**:\n\n";

Now the getData function in the loaded SWF file can be called by the macromedia.swf file. Notice that allowDomain permits any SWF file in the allowed domain to script any other SWF file inthe domain permitting the access, unless the SWF file being accessed is hosted on a site using a secure protocol (HTTPS).

 

Server-side policy files for permitting access to data

TOP

A Flash document can load data from an external source by using one of the following data loading calls: XML.load(), XML.sendAndLoad(), LoadVars.load(), LoadVars.sendAndLoad(), loadVariables(), loadVariablesNum(), MovieClip.loadVariables(), XMLSocket.connect(), and Macromedia Flash Remoting (NetServices.createGatewayConnection). Also, a SWF file can import runtime shared libraries (RSLs), or assets defined in another SWF file, at runtime. By default, the data or RSL must reside in the same domain as the SWF file that is loading that external data or media.

To make data and assets in runtime shared libraries available to SWF files in different domains, you should use a cross-domain policy file. A cross-domain policy file is an XML file that provides a way for the server to indicate that its data and documents are available to SWF files served from certain domains, or from all domains. Any SWF file that is served from a domain specified by the server's policy file is permitted to access data, assets, or RSLs from that server.

If you are loading external data, you should create policy files even if you don't plan to port any files to Flash Player 7. If you are using RSLs, you should create policy files if either the calling or called file is published for Flash Player 7.

 

Allowing cross-domain data loading

TOP

When a Flash document attempts to access data from another domain, Flash Player automatically attempts to load a policy file from that domain. If the domain of the Flash document that is attempting to access the data is included in the policy file, the data is automatically accessible.

Policy files must be named crossdomain.xml, and can reside either at the root directory or in another directory on the server that is serving the data with some additional ActionScript (see About custom policy file locations). Policy files function only on servers that communicate over HTTP, HTTPS, or FTP. The policy file is specific to the port and protocol of the server where it resides.

For example, a policy file located at https://www.macromedia.com:8080/crossdomain.xml applies only to data loading calls made to www.macromedia.com over HTTPS at port 8080.
An exception to this rule is the use of an XMLSocket object to connect to a socket server in another domain. In that case, an HTTP server running on port 80 in the same domain as the socket server must provide the policy file for the method call.

An XML policy file contains a single <cross-domain-policy> tag, which, in turn, contains zero or more <allow-access-from> tags. Each <allow-access-from> tag contains an attribute, domain, which specifies either an exact IP address, an exact domain, or a wildcard domain (any domain). Wildcard domains are indicated by either a single asterisk (*), which matches all domains and all IP addresses, or an asterisk followed by a suffix, which matches only those domains that end with the specified suffix. Suffixes must begin with a dot. However, wildcard domains with suffixes can match domains that consist of only the suffix without the leading dot. For example, foo.com is considered to be part of *.foo.com. Wildcards are not allowed in IP domain specifications.

If you specify an IP address, access is granted only to SWF files loaded from that IP address using IP syntax (for example, http://65.57.83.12/flashmovie.swf), not those loaded using domain-name syntax. Flash Player does not perform DNS resolution.

The following example shows a policy file that permits access to Flash documents that originate from foo.com, www.friendOfFoo.com, *.foo.com, and 105.216.0.40, from a Flash document on foo.com:

<?xml version="1.0"?>

<!-- http://www.foo.com/crossdomain.xml -->

<cross-domain-policy>

<allow-access-from domain="www.friendOfFoo.com" />

<allow-access-from domain="*.foo.com" />

<allow-access-from domain="105.216.0.40" />

</cross-domain-policy>

You can also permit access to documents originating from any domain, as shown in the following example:

<?xml version="1.0"?>

<!-- http://www.foo.com/crossdomain.xml -->

<cross-domain-policy>

<allow-access-from domain="*" />

</cross-domain-policy>

Each <allow-access-from> tag also has the optional secure attribute. The secure attribute defaults to true. You can set the attribute to false if your policy file is on an HTTPS server, and you want to allow SWF files on an HTTP server to load data from the HTTPS server.

Setting the secure attribute to false could compromise the security offered by HTTPS.

If the SWF file you are downloading comes from an HTTPS server, but the SWF file loading it is on an HTTP server, you need to add the secure="false" attribute to the <allow-access-from> tag, as shown in the following code:

<allow-access-from domain="www.foo.com" secure="false" />

A policy file that contains no <allow-access-from> tags has the same effect as not having a policy on a server.
 

About custom policy file locations

TOP

Flash Player 7 (7.0.19.0) supports a method called System.security.loadPolicyFile. This method lets you specify a custom location on a server where a cross-domain policy file can be found, so it does not need to be in the root directory. Flash Player 7 (7.0.14.0) only searched for policy files in the root location of a server, but it can be inconvenient for a site administrator to place this file in the root directory. For more information on the loadPolicyFile method and XMLSocket connections, see About XMLSocket policy files and loadPolicyFile (security.loadPolicyFile method) in the ActionScript 2.0 Language Reference.

If you use the loadPolicyFile method, a site administrator can place the policy file in any directory, as long as the SWF files that need to use the policy file call loadPolicyFile to tell Flash Player where the policy file is located. However, policy files not placed in the root directory have a limited scope. The policy file allows access only to locations at or below its own level in the server's hierarchy.

The loadPolicyFile method is available only in Flash Player 7 (7.0.19.0) or later. Authors of SWF files using the loadPolicyFile method must do one of the following:

  • Require Flash Player 7 (7.0.19.0) or later.

  • Arrange for the site where the data is coming from to have a policy file in the default location (the root directory) as well as in the nondefault location. Earlier versions of Flash Player use the default location.

Otherwise, authors must create SWF files so a failure of a cross-domain loading operation is implemented.

CAUTION : If your SWF file relies on loadPolicyFile, visitors with Flash Player 6 or earlier or Flash Player 7 (7.0.19.0) or later do not have problems. However, visitors with Flash Player 7 (7.0.14.0) do not have support for loadPolicyFile.

If you want to use a policy file in a custom location on the server, you must call System.security.loadPolicyFile before you make any requests that depend on the policy file, such as the following:

System.security.loadPolicyFile("http://www.foo.com/folder1/folder2/crossdomain.xml");

var my_xml:XML = new XML();

my_xml.load("http://www.foo.com/folder1/folder2/myData.xml");

You can load several policy files with overlapping scopes using loadPolicyFile. For all requests, Flash Player tries to consult all the files whose scope includes the location of the request. If one policy file fails to grant cross-domain access, another file is not prevented from granting access to data. If all access attempts fail, Flash Player looks in the default location of the crossdomain.xml file (in the root directory). The request fails if no policy file is found in the default location.

 

About XMLSocket policy files

TOP

For an XMLSocket connection attempt, Flash Player 7 (7.0.14.0) looked for crossdomain.xml on an HTTP server on port 80 in the subdomain to which the connection attempt was being made. Flash Player 7 (7.0.14.0) and all earlier versions restricted XMLSocket connections to ports 1024 and above. However, in Flash Player 7 (7.0.19.0) and later, ActionScript can inform Flash Player of a nondefault location for a policy file using System.security.loadPolicyFile. Any custom locations for XMLSocket policy files must still be on an XML socket server.

In the following example, Flash Player retrieves a policy file from a specified URL:

System.security.loadPolicyFile("http://www.foo.com/folder/policy.xml");

Any permissions granted by the policy file at that location apply to all content at the same level or below in the server's hierarchy. Therefore, if you try to load the following data, you discover you can only load data from certain locations:

myLoadVars.load("http://foo.com/sub/dir/vars.txt"); // allowed

myLoadVars.load("http://foo.com/sub/dir/deep/vars2.txt"); // allowed

myLoadVars.load("http://foo.com/elsewhere/vars3.txt"); // not allowed

To work around this, you can load more than one policy file into a single SWF file using loadPolicyFile. Flash Player always waits for the completion of any policy file downloads before denying a request that requires a policy file. Flash Player consults the default location of crossdomain.xml if no other policies were authorized in the SWF file.

Special syntax allows policy files to be retrieved directly from an XMLSocket server:

System.security.loadPolicyFile("xmlsocket://foo.com:414");

In this example, Flash Player tries to retrieve a policy file from the specified host and a port. Any port can be used if the policy file is not in the default (root) directory; otherwise the port is limited to 1024 and higher (as with earlier players). When a connection is established to the specified port, Flash Player sends <policy-file-request />, terminated by a null byte.

The XML socket server might be configured to serve policy files in the following ways:

  • To serve policy files and normal socket connections over the same port. The server should wait for <policy-file-request /> before transmitting a policy file.

  • To serve policy files over a separate port from normal connections, in which case it might send a policy file as soon as a connection is established on the dedicated policy file port.

The server must send a null byte to terminate a policy file before it closes the connection. If the server does not close the connection, Flash Player does so upon receiving the terminating null byte.

A policy file served by an XML socket server has the same syntax as any other policy file, except that it must also specify the ports to which access is granted. The allowed ports are specified in a to-ports attribute in the <allow-access-from> tag. If a policy file is less than port 1024, it can grant access to any port; when a policy file comes from port 1024 or higher, it can grant access only to other ports above 1024. Single port numbers, port ranges, and wildcards are allowed. The following code is an example of an XMLSocket policy file:

<cross-domain-policy>

<allow-access-from domain="*" to-ports="507" />

<allow-access-from domain="*.foo.com" to-ports="507,516" />

<allow-access-from domain="*.bar.com" to-ports="516-523" />

<allow-access-from domain="www.foo.com" to-ports="507,516-523" />

<allow-access-from domain="www.bar.com" to-ports="*" />

</cross-domain-policy>

Because the ability to connect to ports lower than 1024 is available in Flash Player 7 (7.0.19.0) and later, a policy file loaded with loadPolicyFile is always required to authorize this, even when a SWF file is connecting to its own subdomain.
 

HTTP to HTTPS protocol access between SWF files

TOP

You must use an allowDomain handler or method to permit a SWF file in one domain to be accessed by a SWF file in another domain. However, if the SWF file being accessed is hosted at a site that uses a secure protocol (HTTPS), the allowDomain handler or method doesn't permit access from a SWF file hosted at a site that uses an insecure protocol. To permit such access, you must use the LocalConnection.allowInsecure Domain() or System.security.allowInsecureDomain() statements.

 

Allowing HTTP to HTTPS protocol access between SWF files

TOP

In addition to the exact-domain matching rules, you must explicitly permit files hosted at sites using a secure protocol (HTTPS) to be accessed by files hosted at sites using an insecure protocol. Depending on whether the called file is published for Flash Player 6, 7, or 8, you must implement either one of the allowDomain statements (see Cross-domain and subdomain access between SWF files), or use the LocalConnection.allowInsecure Domain or System.security.allowInsecureDomain() statements.

For example, if the SWF file at https://www.someSite.com/data.swf must allow access by a SWF file at http://www.someSite.com, the following code added to data.swf allows this access:

// Within data.swf

System.security.allowInsecureDomain("www.someSite.com");

my_lc.allowInsecureDomain = function(sendingDomain:String):Boolean {

return (sendingDomain == "www.someSite.com");

};

WARNING : Implementing an allowInsecureDomain() statement compromises the security offered by the HTTPS protocol. You should make these changes only if you can't reorganize your site so that all SWF files are served from the HTTPS protocol.

The following code shows an example of the changes you might have to make:

// Commands in a Flash Player 6 SWF file at https://www.someSite.com

// to allow access by Flash Player 7 SWF files that are hosted

// at http://www.someSite.com or at http://www.someOtherSite.com

System.security.allowDomain("someOtherSite.com");

my_lc.allowDomain = function(sendingDomain) {

return(sendingDomain=="someOtherSite.com");

}

// Corresponding commands in a Flash Player 7 SWF file

// to allow access by Flash Player 7 SWF files that are hosted

// at http://www.someSite.com or at http://www.someOtherSite.com

System.security.allowInsecureDomain("www.someSite.com", "www.someOtherSite.com");

my_lc.allowInsecureDomain = function(sendingDomain) {

return(sendingDomain=="www.someSite.com" ||

sendingDomain=="www.someOtherSite.com");

}

You might also have to add statements such as these to your files if you aren't currently using them. A modification might be necessary even if both files are in the same domain (for example, a file in http://www.domain.com is calling a file in https://www.domain.com).

To summarize, you might have to modify your files to add or change statements if you publish files for Flash Player 7 or later that meet the following conditions:

  • You implemented cross-SWF file-scripting (using loadMovie(), MovieClip.loadMovie(), MovieClipLoader.LoadClip(), or Local Connection objects).

  • The calling file is not hosted using an HTTPS protocol, and the called file is HTTPS.

You must make the following changes:

  • If the called file is published for Flash Player 7, include System.security.allowInsecureDomain or LocalConnection.allowInsecureDomain in the called file, using exact domain-name matching, as shown in the code examples earlier in this section.

  • If the called file is published for Flash Player 6 or earlier, and both the calling and called files are in same domain (for example, a file in http://www.domain.com is calling a file in https://www.domain.com), no modification is needed.

  • If the called file is published for Flash Player 6, the files are not in same domain, and you don't want to port the called file to Flash Player 7, modify the called file to add or change a System.security.allowDomain or LocalConnection.allowDomain statement, using exact domain-name matching, as shown in the code examples earlier in this section.

  • If the called file is published for Flash Player 6 and you want to port the called file to Flash Player 7, include System.security.allowInsecureDomain or LocalConnection.allowInsecureDomain in the called file, using exact domain-name matching, as shown in the code examples earlier in this section.

  • If the called file is published for Flash Player 5 or earlier, and both files are not in the same domain, you can do one of two things. You can either port the called file to Flash Player 6 and add or change a System.security.allowDomain statement, using exact domain-name matching, as shown in the code examples earlier in this section, or you can port the called file to Flash Player 7, and include a System.security.allowInsecureDomain statement in the called file, using exact domain-name matching, as shown in the code examples earlier in this section.

Copyright ADOBE - All Rights Reserved Worldwide

 

 

More Topics:

Working with Flash Documents

How to work in Flash WorkSpace

Working with Projects in Flash

Process to Build your First Application in Flash

Using Symbols, Instances and Library Assets in Flash

How to Build Video Player in Flash

How to Work with Color, Strokes and Fills in Flash

How to Create Document in Flash

What is Vector and Bitmap Graphics in Flash

How to Create a Banner in Flash, Part 1

How to Work with Text in Flash

How to Create a Banner in Flash, Part 2

How to Use Imported Artwork in Flash

How to Create a Banner in Flash, Part 3

How to Work with Graphic Objects in Flash

How to Work with Layers in Flash

How to Use Filters and Blends

Working with Graphics in Flash

What is Accessibility Features in Flash

How to Create Motion (Shape Tween & Motion Tween) in Flash

How to Create an Application in Flash

What is Masking in Flash

How to Work with Video in Flash

How to Use Layout Tools in Flash

What are Behaviors in Flash

How to Work with Sound in Flash

How to Create Symbols and Instances in Flash

What is ActionScript in Flash

How to Write ActionScript With Script Assist in Flash

How to Add Button Animation and Navigation in Flash

What is Data Integration in Flash

How to Work with Screens

How to Create a Presentation with Screens

What is Extending Flash

How to Create Multilanguage Text in Flash

How to Create Graphics: Draw in Flash

What is Flash Lite

Ways of Data Integration

How to Create Graphics: Create a Timeline Animation in Flash

Getting Started with Flash Lite in Flash

How to Publish Flash Documents

How to Create Graphics: Making Animations with Easing

Learning Flash Lite 1.X ActionScript in Flash

How to Export Flash Content and Images from Flash

How to Create Graphics: Applying Gradients in Flash

Process of Writing and Editing ActionScript 2.0 in Flash

How to Create Accessible Content in Flash

How to Create Graphics: Apply Graphic Filters and Blends

What is Data and Data Types in Flash

Process of Printing from SWF Files in Flash

Using ActionScript: How to Use Script Assist mode in Flash

Learn Syntax and Language Fundamentals in Flash

How to Create E-learning Content in Flash

Using ActionScript: How to Write Scripts in Flash

Working with Functions and Methods in Flash

Process of Using Templates in Flash

Using ActionScript: Process of Adding Interactivity in Flash

What are Classes in Flash

Control Tag Summary of XML to UI in Flash

Using ActionScript: How to Create a Form with Conditional Logic and Send Data in Flash

What is Inheritance in Flash

What is Data Integration: Overview

Using ActionScript: How to Work with Objects and Classes in Flash

Overview on Interfaces in Flash

What is Data Integration: Using XML for a Timesheet

How to Work with Text and Strings in Flash

How to use Handling Events in Flash

What is Data Integration: Using XUpdate to Update the Timesheet

Learning Animation, Filters and Drawings in Flash

How to Work with Movie Clips in Flash

How to Create Interaction with ActionScript in Flash

How to Work with Images, Sound, and Video in Flash

How to Work with External Data in Flash

What is Security in Flash

How to Debug Applications in Flash

List of Error Messages in Flash

Using Object-Oriented Programming with ActionScript 1.0 in Flash

How to Write Scripts for Earlier Versions of Flash Player in Flash

List of all Keyboard Keys and Key Code Values for using in Flash

Terminology

Introduction to Components in Flash

What are Components in Flash

How to Create an Application with Components

How to Work with Components in Flash

How to Handle Component Events in Flash

How to Customize Components in Flash

How to Create Components in Flash

What is Collection Properties in Flash