- Using ActionScript in Flash
- Why the Move to ActionScript 2.0
- Working with Classes
- Error Handling
- Security in the Flash 7 Player
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Security in the Flash 7 Player
An area that you cannot afford to take lightly is security. It appears that not a single week goes by when some hacker is attempting to break into one system or another.
Fortunately, Flash has a track record of amazing security. Over the last seven years, I am aware of only one security flaw in the Flash Player (it was resolved within a month by a new version of the Flash Player from Macromedia). Macromedia wants to keep the good image of Flash first and foremost in users' eyes.
To help this, Flash is now by default allowing content on only the same server as the SWF movie to load in additional movies, media, or data. This means if you have your SWF file on http://www.youwebsite.com, but your Flash video is on media.yourwebsite.com, you cannot import the video into Flash. Equally, you cannot connect to a Web Service and pull/push the information into the Flash Player.
This does seem very restrictive. The protection Macromedia is providing, however, is that that you cannot have your Flash movie highjacked. The challenge you can probably see, however, is that you do not keep all of your content on one server. Particularly data that can be dispersed all over your company on different servers.
The solution is with the new Flash policy file. A policy file is an XML file you can place at the root of your Web server. The file allows Flash to load items for one or multiple different domains.
You must ensure that the policy file resides on the server you are linking to. If you do not, the Flash movie will not load the information.
Creating a policy file is not very hard. The entire document is an XML file. The best way to create a new policy file is to open your favorite text editor and create a new XML file called crossdomain.xml. It is very important that you name the file crossdomain.xml because it is a keyword name that Flash uses to look up policy files.
Open the XML file and enter the following code:
<?xml version="1.0"?> <!-- http://www.informit.com/crossdomain.xml --> <cross-domain-policy> <allow-access-from domain="http://www.informit.com" /> <allow-access-from domain="*.informit.com" /> <allow-access-from domain="121.69.95.10" /> </cross-domain-policy>
The XML code here allows you to define which sections of your Web site are open to the public. To define it, you used the allow-access-from parameter. In the above example, the first parameter lets the Flash Player access content only on the InformIT Web site. Any other subsites, such as media.informit.com, will be ignored.
The second line allows access to *.informit.com, where the * is a wildcard that allows the Flash Player to link to any subdomain Web site.
The final allow-access-from parameter links directly to a computer's IP address.
If you want to open your entire site, you can do so easily by adding the crossdomain.xml to your site, but with no content. If there are no allow-access-from parameters set, the Flash Player will automatically set the entire domain and subdomains as fully accessible.
Using the policy file can become a problem with large public Web Services such as Google that do not have a Flash policy file. The way around this is to connect to the Web Service with either .NET, Java, or ColdFusion on the server and pass that onto the local file. Another way around the policy file is to run the Flash movie as a downloaded executable. The Flash movie is then running off your hard drive and not through your Web browser.
The end result is that you may have a little more work, but Flash is a more secure solution. As you develop more applications with Flash, you will be grateful that Macromedia is taking this initiative seriously.