TREVOR.MORSE

FRAPI VM

We had been discussing creating a VM for FRAPI for quite a while now. So prompted by this tweet from @beriberikix I finally sat down and put something together in VMWare. Though it was created in VMWare you should be able to import it into VirtualBox.

It is a base Ubuntu 10.10 32-bit server install with everything necessary to power FRAPI including nginx, php-fpm and all the necessary libraries. The username and password to get logged in are “frapi”. Nginx is configured to serve the admin interface as http://admin.frapi and the api itself as http://api.frapi.

All you should need to get things going is to fire up the VM, login and determine the ip, then make a host entry for both admin.frapi and api.frapi on your machine pointing to that ip.

I am definitely not a sys admin so this VM should not be considered ready for production and should only be used for testing and development. However, if you do have suggestions for better configurations or just ways to make the VM better then hop on #frapi on freenode and let us know!

You can grab the VM here:

FRAPI VM

Accessing FRAPI with Flash

Over the past few weeks I have been building some REST API’s for work using FRAPI. If your building RESTful API’s you should definitely head over to http://getfrapi.com and check it out!

The latest project was to power a flash application that would be making calls directly to FRAPI. FRAPI was set up on a different domain then the flash that would be calling it, so it needed a crossdomain.xml file in the root to allow access.

Of course by default FRAPI would handle that request with rewrite rules and map it to an XML request to the crossdomain action. When flash tries to access this file it gets the default error response, instead of the expected XML content.

<?xml version="1.0" encoding="UTF-8"?>
<response>
    <errors>	
        <error code="ERROR_INVALID_ACTION_REQUEST">
            <message>Invalid requested action</message>
            <name>ERROR_INVALID_ACTION_REQUEST</name>
            <at></at>
        </error>
    </errors>
</response>

So there were two options, modify the apache rewrite rule, or create an action in FRAPI to handle it.

The apache rewrite rule is fairly easy and quick to implement, and simply needs to go in the .htaccess file before the normal rewrite rules.

RewriteCond %{REQUEST_FILENAME} !-f

This simply checks that the request is not for an actual file before processing any of the rewrite rules FRAPI normally applies.

However, my preference was to create an action in FRAPI to keep everything in the Custom directory of FRAPI as that is what we stored in our version control system so that we can easily upgrade/deploy to a new version of FRAPI and not have to worry about our code being overwritten, or losing our modifications to .htaccess.

The first thing I did was create an action that was enabled, public and had a custom route of “crossdomain”, no code required as we are not doing any processing. All that was needed after that was to create a Crossdomain.xml.tpl (substitue Crossdomain for whatever you named your action) file in the custom/Output/xml/ directory of our FRAPI install with the following content.

<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

Voila! The next time crossdomain.xml is accessed you will get the proper XML response and flash will be happy. Below is a sample of the output.

<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>