Effortless Flex 4 Development: Flash Security Model
From the book
From the book
From the book
Flash Security Model
Before getting into some client-server interactions, you should have an understanding of the Flash Player security model. The Flash Player, for security purposes, creates a sandbox in which the Flash Player is allowed to do its thing. By restricting its actions within that sandbox, the Flash Player cannot be maliciously used to do bad things, such as muck around on the user's computer.
One aspect of this sandbox is that, by default, a Flash program on one domain (a domain being www.example.com) cannot retrieve data from another domain (like www.dmcinsights.com). This is known as a Same Origin Policy, and is also a restriction present when using Ajax (i.e., don't think Flash is just being difficult). In order to overrule this default restriction, you'll need to create a cross-domain policy file.
A cross-domain policy file is an XML document with the name crossdomain.xml. Its root tag is cross-domain-policy, so it starts like so:
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/ xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> </cross-domain-policy>
Within the root element, the domain's policy can be established. The tag to use is allow-access-from. Assign to its domain property the domain that should be allowed to connect. For example, say you develop a Flash application that's going to run from www.example.com that needs to make use of resources found on www.example.info. You would create, on www.example.info, a crossdomain.xml file that contains the following:
<cross-domain-policy> <allow-access-from domain="www.example.com" /> </cross-domain-policy>
If you wanted content on www.example.info to be available to both www.example.com and its subdomain shop.example.com, then the file would contain
<cross-domain-policy> <allow-access-from domain="www.example.com" /> <allow-access-from domain="shop.example.com" /> </cross-domain-policy>
If you are running a site that provides services that should be available from any domain, the policy file would be defined as
<cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
The asterisk is the wildcard, meaning that any domain is allowed to connect. This is essentially a disabling of any security restriction and should never be used on your own sites without other measures in place. For example, many public services require an authorization ID so that only registered applications can make use of the services.
The allow-access-from tag has an optional secure attribute. If you set this to true, then a secure connection must be made from the Flash application to the server.
<cross-domain-policy> <allow-access-from domain="*" secure="true" /> </cross-domain-policy>
The crossdomain.xml file is normally placed in the root directory (i.e., the folder that www.example.com points to). If the policy file is stored in a subdirectory, then it only applies to that subdirectory (and its subdirectories). To be absolutely clear, this isn't placed on the same computer as the Flash application itself: The Flash application already has access to its own domain.
For the purposes of the rest of this book, I'll explain how to set up a server on your own computer. This way you can create, run, and debug your Flex applications locally. In this case you won't need to worry about cross-domain policy issues. Still, this is something to be aware of as you go forward and begin using services from other domains.
While discussing security, I want to reinforce the point that you must validate data being transmitted back and forth between the client and server. In particular, you want to validate user-supplied information in Flash, prior to sending it to the server, and validate that same data on the server, prior to using it in a database query or doing anything else potentially dangerous with it. You should also be cautious with server-provided data that will be used in a Flash application. You'll see plenty of examples in this chapter and the next for using data safely.