One of the most typical problems when coding AS3 to, let’s say, read data from an external XML source, is the cross-domain problem. According to security policies, not an url outside the domain where the AS application is being executed can be read, and different subdomains (such as www.yourdomain.com and yourdomain.com) are considered as different ones.
If the external resources you are trying to use come from your own application in another domain / server that you manage, then it can be fixed by adding a cross-domain policy file. This file must be defined on the content source server, and your AS application has to explicitly declare this server as allowed.
But if this is not the case and the content source is on a different remote server like, for instance, when implementing an RSS news reader which grabs content from sources like online news sites, then this problem can be worked out with a PHP proxy file.
$url = $_GET['url']; readfile($url);
Since PHP is not affected by this policy, all the RSS feeds would be read through this small script, by calling it like ‘proxy.php?url=http://rss.thedomain.com’. Being this file exactly on the same domain than the AS application, the cross-domain problem is solved.
However, I have also found an odd behavior regarding this proxy PHP file: it works perfectly when opening the SWF compiled application directly on the browser (http://yourdomain.com/app.swf), but not when it is loaded as a part of the HTML code (embedded into an HTML page like http://yourdomain.com/app.html). The SWF application just doesn’t find the file (but it is there!), despite it reads without any problem a test text file on the same folder. So it seems as if the question mark ‘?’ changed the way the SWF application looks for files or executes url addresses. I don’t have a reason for this yet, but I guess that it is related to the way the Flash plugin manages the security, by using different sandboxes for direct and embedded executions of the application.
The solution for this second collateral problem is passing the domain name as a parameter, so that the full path to the proxy file can be constructed inside the AS application.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
1 2 3 4 5 6 7 8 9 10 11 12 13
var proxyPath:String = this.loaderInfo.parameters.basepath + 'proxy.php'; // proxy for cross-domain problems
In any case, these problems only arise in online mode, I have not had any issue while working from my development suite, so it is when moving to a production environment when the pain in the ass can show out. Finally, this is nothing new, but handy and interesting not to forget.