- What's new
- Installing Remoting components
- Installing AMFPHP
- Testing AMFPHP
- 10,000 foot view of Remoting
- Creating Remoting methods
- Method table reference
- Helper classes
- Class mapping
- Sending recordsets
- Manual recordsets
- Pageable recordsets
- Consuming web services (SOAP)
- Other platforms
- The service browser
- Debugging primer
- NetConnection debugger
- Debugging proxies
- NetDebug::trace and exceptions
- Common confusing errors
Deploying AMFPHP on a live server
It is possible that a service you developed locally will fail remotely. Chances are the development environment will not mimic perfectly the deployement environment.
Case sensitivity issues
Case-sensitivity issues. The filenames are case-sensitive on Unix/Linux, but not on Windows, so if you are getting errors such as ‘the service does not exist’ double check the names
crossdomain.xml - security sandbox issues
Since Flash 6, the Flash player implements a security sandbox. If your swf file is located on one domain and the gateway.php file on another, remote calls will fail. This is true of subdomains as well, meaning you won't be able to call myserver.com from www.myserver.com. The solution is to use a crossdomain.xml file. Instructions are available at 5 1/2 and at Macromedia. See also why crossdomain.xml is a good thing.
With Flash 8, there is an additional restriction on whether you can load only local files or only remote files. You should open your fla, go into File > Publish Settings, and under the Flash tab, at the bottom of the screen, set 'Local playback security' to 'Access network only'.
There have been reports that Apache installations with mod_security enabled can cause issues. In particular, mod_security may be set to disallow any unknown content-types, and AMFPHP uses the application/x-amf content type. In your Apache error log, this will show up as:
mod_security: Access denied with code 404. Pattern match "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)" at HEADER("Content-Type")
The pattern match outlined above should be defined in /etc/httpd/conf.d/mod_security.conf. If not there, it could be in /etc/httpd/conf/httpd.conf. If not, you should be able to find it using
find /etc/httpd/ -name "*security.conf"
You should find a line such as this:
SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"
Change it to:
SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^application/x-amf|^multipart/form-data)"
Restart Apache and it should work. If you don't have global access to the *.conf files, you may be able to achieve the same effect with a .htaccess file in the amfphp diretory:
<IfModule mod_security.c> SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^application/x-amf|^multipart/form-data)" </IfModule>
There have been reports that amfphp may not work in IIS if gateway.php and the services folder are set to 'read-only'. Make sure you give full permissions to amfphp if you want it to work correctly on IIS.
If you do not want other sites to load your services (leeching) and you are using Apache, you can set up a .htaccess file to redirect undesirable calls to a dead-end. Read about using mod_rewrite to stop leeching.
In addition, if you want to block various sensitive information about your server from being sent back to the client, you can set the PRODUCTION_SERVER constant to true in gateway.php, which will block remote tracing, service descriptions and the standalone player.