Flash MX 2004 RSS Reader Pg.3
source: http://www.thegoldenmean.com
3 — Coping With Security Limitations
Working Around the Security Sandbox
What it is
Stated quite simply, Macromedia does not permit the Flash Player 7 to load data from remote domains using the load() or sendAndLoad() methods of the XML or LoadVars Objects.
If that superficial statement doesn’t satisfy you, some further reading includes
- Macromedia Flash Technote: "Macromedia Flash Security Sandbox",
- Macromedia Flash Technote: "External data not accessible outside a Macromedia Flash movie's domain",
- Steven Webster’s article at Devnet: Choosing Between XML, Web Services, and Remoting for Rich Internet Applications, and
- Colin Moock’s technote: cross domain security files.
Note that this limitation does not apply to the development environment or to stand-alone projector files. These will both load data from anywhere. A compiled .swf playing in Player 7 or later will not.
Why it is
Quite frankly, I don’t know. I have yet to encounter a concise explaination of what sort of mischief this prevents. This is probably intentional, to keep amateur hackers from getting any bright ideas. Whatever. All we need to know for the moment is that we need some way to load data from a remote domain so we can present it in a Flash movie.
The PHP Solution
Flash will not load XML data from a remote domain without a security document (a “policy file“) at the remote domain. We are not likely to be able to persuade bloggers to put policy file documents on their sites just for us. How can we make the XML from a remote domain appear to be a local file to Flash? One solution is to write a script in PHP that will exist in the same domain as the Flash movie and will transparently pass the data to Flash, making it appear as if it is the document itself. This type of script is referred to as a “proxy”: it becomes a surrogate for the actual document.
If you are new to PHP…
Please note that PHP scripts won’t execute without a web server. You might have a server such as Apache on your local computer, in which case testing locally will (probably) work. If not, you will need to post your .swf, html and PHP files to a real web server to test them.
Simple example code:
Marty Smith, one of my patient PHP tutors, wrote this script for the first version of my news reader. I was stunned by how little code was required:
<?php $rss = $_GET['rss']; readfile($rss); ?>
That’s all it took! The script is written to expect to receive the URL of a syndicated blog feed via a GET query string such as:
rssProxy.php?rss=http://www.someDomain.com/someDocument.xml
Then the PHP function readfile() does what it does: “Reads a file and writes it to the output buffer.” (source: PHP manual).
When loaded into Flash using the standard XML load() method, Flash accepts the proxy as the document itself and we are off to the races.
Slightly more robust code
Michael Gunn of HollowCube posted this slightly more secure script on the We’re Here Forum:
<?php
$rss = $_GET['rss'];
// make sure that some page is really being called
if ($rss && $rss != ""){
// make sure that an http call is being made - otherwise there's access to any file on machine...
if ((strpos($rss, "http://") === 0) || (strpos($rss, "https://") === 0)){
readfile($rss);
}
}
?>
This is marginally more secure than the first example on this page, but not by much. It checks to see if there is data in the proper query term, and whether that data utilizes the http or https protocols (designed to prevent someone from using the readfile function to rummage around your site for anything interesting).
For the moment, either one of these scripts will do the job. I used the first example on my site for years with no problems I was aware of, but there is no doubt it presents an open door for the bad guys. We will revisit the Proxy issue on page 12 and write a more secure version.
It was critical to deal with the Proxy script at the beginning. Now that we have the tool to load a document into Flash we must turn our attention to what to do with the XML we get back. The next page outlines my first painful approach which I call The Blunt Instrument.
--top--