There’s a lot of options when working on a flash project across multiple domains. Here’s an overview of the different elements to be concerned about. (continuing to be created)
A word about security..
Only set the security to as lose as you need it to be in order to achieve the communication required. Setting security settings to wide open is a huge risk, especially for enterprise applications.
These are settings that can be tweaked outside of flash/flex; either on the page that calls it or in an additional external file.
These are the first defense in setting what files can load files from other domains. Place a file like this on a domain that contains the content you want to load into a swf sitting on another domain. Note that the latest set of crossdomain policy file updates allow for multiple levels of policy setting to allow web masters finer control over a domain umbrella policy. Of course Adobe is the best place to look for the policy documentation, it can be a bit much especially with the new additions allowing for more granularity. Many of the numerous additions are only for other protocols like socket connections or for site master policy files.
If you are trying to make a request for dynamic data, xml flat files from a different server than where the swf originates you will most likely see a request for a crossdomain.xml file and not see the request for your actual call. If you are trying to pull in a bitmap from another domain, by default the loaderContext will not request the policy file unless you tell it to. Then it will look for a cross domain policy file to allow you to access the content of the bitmap(this is partly to stop people from loading images from another domain and using someone elses bandwidth or preventing copying of the pixels).
This security element allows flash to do things like execute JavaScript on the page that’s calling it. This is one of the most common security settings that needs to be set. Applications that live on the same server as they are called from still require this to be set to call JavaScript. Since most analytics packages rely on flash to JavaScript to make calls (although google analytics and Omniture are creating packages to make their calls fully from within flash) this will need to be set for those features as well as deeper flash/js functionality.
If you are looking to call JavaScript from within your flash file with a navigateToURL or ExternalInterface call you will probably need to set this.
This security element allows flash to make use of other networking protocols.
These are changes that need to be made internal to the SWFs that get deployed.
This is a function call that can be done from within your SWFs. This states that this specific swf allows another domain to access it. This can mean another swf from another domain and also an ExternalInterface call from another domain to call.
Allows all domains to be available
Allows anything that originates at domain.com or subdomains to have access
Allows access from an IP. Note: Security.allowDomain(“192.168.1.10”); is not a valid domain.
ApplicationDomain is important for knowing what classes are treated as the same class in two different swfs. There are three main values for ApplicationDomains:
Set this when you want a parent swf to use the same classes as a child swf and treat them as the same. Note that you’ll want to make sure that you continue to publish all the files in your project to make sure no swfs have an old version of one of the classes in it.
Set this when you want to have a separate sandbox
more to come
more to come
Nate is currently a Senior Presentation Layer Architect at Razorfish Chicago. As an SPLA Nate: participates in technology leadership team and resource allocations, manage fulltime and contractor resources, represents technology for groups of brands across multiple clients, furthers development of standards within the office, architects project implementations and fosters community and mentoring.