Copyright © 2009 Adobe Systems Incorporated. All rights reserved.
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-08-2008).
Search powered by Google™
Adobe tightened the rules regarding Flash Player and cross-domain policy files starting with Flash Player 9,0,115,0. Due to the impact of these changes and how they would affect many existing websites, the changes took place over a series of three phases in multiple releases of Flash Player.
Flash Player 9,0,115,0 implemented Phase 1. Following that, Flash Player 9,0,124,0 continued with Phase 1.5: strict rules for sockets only. Flash Player 10 will complete Phase 2 including cross-domain policy file changes for all other non-socket content (HTTP/HTTPS/FTP).
The completion of Phase 2 changes the default behavior of the meta-policy for policy files. A meta-policy is a policy that dictates the behavior of policy files on a domain, enablng an administrator to exercise greater control over all policy files being used with that domain. The concept of meta-policies was introduced in Phase 1 with Flash Player 9,0,115,0. For that version of the player, the meta-policy used a default value of "all," which allowed all policy files on a domain to remain valid; this allowed the behavior to remain consistent with previous versions of the player.
With Phase 2 in Flash Player 10, the meta-policy default will change from "all" to "master-only." This will allow all master policy files (any policy file saved in the root of the domain with the name crossdomain.xml, such as http://example.com/crossdomain.xml) to continue to function as expected. However, all other policy files defined in alternate locations will require an explicit meta-policy for them to work.
This change can potentially affect any SWF file accessing cross-domain content. This change affects SWF files of all versions played in Flash Player 10 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Read the article, Policy file changes in Flash Player 9 and Flash Player 10.
If you have not already, define a meta-policy for your domain. Even if you are only using a master policy file, it is recommended you still explicitly define a meta-policy. Meta-policies can be set in the master policy file within a site-control directive, or through headers sent by the server.
If you depend on content from a domain outside of your control, you should contact that domain's administrator and make sure they have a meta-policy that is up to date.
For ActionScript Socket and XMLSocket objects, all securityError events will be sent after a predetermined
amount of time has elapsed since the call to connect(). This means
that previously immediate securityError events will take longer to be
dispatched, and also that connections that might earlier have succeeded after a
long delay (for example, because of network congestion or outages) will instead
result in a securityError event. The predetermined timeout is 20 seconds
by default but can be specified by ActionScript developers using the new Socket.timeout and XMLSocket.timeout APIs.
This change can potentially affect any SWF file that uses
the Socket or XMLSocket classes. This change affects SWF files of all versions played in Flash Player
10 and later. This change affects all non-app content in Adobe AIR (however,
AIR app content itself is unaffected).
Developers should be sure to account for the new error by
listening for the SecurityErrorEvent.SECURITY_ERROR event from Socket and XMLSocket objects in their code. An explicit timeout may also be set. Longer timeouts
favor greater robustness under marginal network conditions at the expense of
longer delays in discovering failures. Shorter timeouts favor quicker discovery
of failures at the expense of reduced robustness under marginal network
conditions.
In Flash Player 9, ActionScript could perform uploads and
downloads at any time. With Flash Player 10, the FileReference.browse and FileReference.download operations may be
initiated only through ActionScript that originates from user interaction. This
includes actions such as clicking the mouse or pressing the keyboard.
This change can potentially affect any SWF file that makes
use of Filereference.browse or FileReference.download. This change affects SWF files of
all versions played in Flash Player 10 beta and later. This change affects all
non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Any existing content that invokes a browse dialog box using Filereference.browse or FileReference.download outside of an event triggered by user interaction will need to be updated. The
dialog box will now have to be invoked through a button, keyboard shortcut, or
some other event initiated by the user.
In Flash Player 9, ActionScript could set data on the system Clipboard at any time. With Flash Player 10, the System.setClipboard() method may be successfully called only through ActionScript that originates from user interaction. This includes actions such as clicking the mouse or using the keyboard. This user interaction requirement also applies to the new ActionScript 3.0 Clipboard.generalClipboard.setData() and Clipboard.generalClipboard.setDataHandler() methods.
This change can potentially affect any SWF file that makes use of the System.setClipboard() method. This change affects SWF files of all versions played in Flash Player 10 and later. This change affects all non-application content in Adobe AIR—however, AIR application content itself is unaffected.
Any existing content that sets data on the system Clipboard using the System.setClipboard() method outside of an event triggered by user interaction will need to be updated. Setting the Clipboard will now have to be invoked through a button, keyboard shortcut, or some other event initiated by the user.
Some HTTP servers sometimes send a response header that looks like this:
Content-Disposition: attachment
The purpose of this response header is to indicate to client software (browsers, Flash Player, e-mail clients, etc.) that the file being returned should not be rendered inline as active content. For example, imagine you're reading e-mail messages on a web-based service and you click a link that represents a file attached to a message. The server may well respond with "Content-Disposition: attachment"—meaning, "Hey, browser, don't open this file. Save it to disk instead." This header can sometimes serve a security purpose: If a server provides files that were uploaded by untrusted users, the "Content-Disposition: attachment" header can help prevent those files from being executed in the server's domain.
Starting with version 10,0,2, if Flash Player sees a "Content-Disposition: attachment" header while downloading a SWF file, it will ignore the SWF file rather than play it. Note that this restriction applies only to SWF files and not to other types of content, such as images, sounds, text, or XML files, policy files, etc.
This change will affect any SWF file whose HTTP server specifies "Content-Disposition: attachment" while serving the SWF file. This change affects SWF files of all versions played in Flash Player 10,0,2 and later. This change affects all non-app content in Adobe AIR (however, AIR application content itself is unaffected).
If you control the HTTP server on which the SWF file resides, determine whether you trust the SWF file to execute in the server's domain. If so, remove the "Content-Disposition: attachment" header by changing your HTTP server's configuration.
If you do not control the HTTP server on which the SWF file resides, you have two options:
URLLoader or URLStream class to download the loadee SWF, rather than the Loader class as usual. After the loadee SWF has finished downloading, call Loader.loadBytes to transform the SWF data into a running SWF file. Note that this technique may not work because the loadee SWF may refer to relative URLs or rely on security sandbox privileges that are not available from the loading SWF's context.The following properties of ActionScript 3.0 events contain references to DisplayObject instances:
mouseOver, mouseOut, rollOver, or rollOut event, this property refers to the other object, if any, that was involved in the change of objects underneath the mouse pointer—the object that either was previously or is currently under the pointer. mouseFocusChange, keyFocusChange, focusIn, or focusOut event, this property refers to the other object, if any, that was involved in the change of focus—the object that is either relinquishing or taking focus. menuSelect or menuItemSelect event, this property refers to the object, if any, over which the context-click (right-click or Control-click) occurred. Starting in Flash Player 10.0.2, if an object that would be referred to by any of these properties resides in a different security sandbox (for example, because it is part of a different SWF that was served from a different domain), and the two sandboxes do not both trust each other (by means of the Security.allowDomain method), then the value of this property is changed to null.
These properties can already have null values—for example, when a user rolls over an object from the background. This change merely introduces new situations where a null value can be found.
If SWF files wish to determine whether a null value resulted from this restriction, they can check the values of three new Boolean properties:
MouseEvent.isRelatedObjectInaccessibleFocusEvent.isRelatedObjectInaccessibleContextMenuEvent.isMouseTargetInaccessibleThis change can potentially affect any SWF file that refers to the MouseEvent.relatedObject, FocusEvent.relatedObject, or ContextMenuEvent.mouseTarget properties. This change affects SWF files of all versions played in Flash Player 10,0,2 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
Your SWF file may continue to work without problems. Test your event handlers to see if they react properly. If there are problems, identify which other SWF file(s) are involved in the overlap of event information. If possible, have both SWF files call Security.allowDomain, specifying each other's domains. However, do not call Security.allowDomain without understanding the impact this will have—in particular, do not call Security.allowDomain if you do not trust the specified domain with the privilege of arbitrarily scripting your SWF file.
When a SWF file performs an upload to a server, using the FileReference.browse and FileReference.upload methods, Flash Player enforces two security rules:
FileReference.browse must be called from within a user-event handler (mouse or keyboard event)FileReference.upload, a policy file is required on the target server, trusting the domain of the SWF fileStarting with version 10,0,2, Flash Player enforces these same two rules at the time any networking API is called to perform a POST that will appear to the server to contain an upload. The format for these uploads is called RFC1867, and it consists of a Content-Type of "multipart/form-data", with a section in the POST body that includes a "filename" attribute in a "Content-Disposition" header.
This change can potentially affect any SWF file that makes use of any networking API to send a POST request that contains an RFC1867 upload. This change affects SWF files of all versions played in Flash Player 10,0,2 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
If this restriction causes your SWF content to stop working as intended, you will need to modify and republish the SWF file.
If you control the server to which the POST is being sent, you can change both the SWF and the server to use an alternate format for transmitting files, or just different syntax within the multipart format. If you avoid using the "filename" keyword, Flash Player will not treat your POST as an upload.
If it is a requirement that you use RFC1867 syntax, then try to ensure that you make your POST call from within a user-interaction handler, and that the server contains a policy file trusting your SWF's domain if you are POSTing to a server other than the SWF's own origin server.
Starting with version 10,0,2, Flash Player will not permit use of camera or microphone, or display of the Settings UI, when any of the following conditions are present:
The Settings UI is the inline UI visible when users right-click or Control-click on SWF content and choose Settings.
This change can potentially affect, on Linux only, any SWF file that is sourced with a "wmode" attribute of "transparent" or "opaque", and that makes use of Camera or Microphone APIs. This change affects SWF files of all versions played in Flash Player 10,0,12 and later. This change affects all non-app content in Adobe AIR (however, AIR app content itself is unaffected).
The "direct" and "gpu" modes are new in Flash Player 10, so no previously published SWF content should be affected by the "direct" and "gpu" restrictions.
If you are affected by this restriction, try changing your "wmode" setting to "window" (the default).
Copyright © 2009 Adobe Systems Incorporated. All rights reserved.
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-08-2008).
Search powered by Google™
