Before our web-based application will be able to work with the Facebook Graph API, it will need the Facebook JavaScript SDK to be included in the host HTML page, and it will have to be hosted on a domain or subdomain specified in our Facebook Application settings.
The Facebook JavaScript SDK is what makes it possible for our Flash Player application to obtain details of any active Facebook sessions, and it allows our application to perform actions such as prompting for authentication or requesting additional permissions.
In this recipe we will be extending our web project's default HTML template file to include the Facebook JavaScript SDK. In addition, we also have some more settings to change for our application in the Facebook Developer center—setting up the online Canvas or Tab page URLs, as well as the domains and subdomains which are allowed to access the Graph API.
For our Flash Player application to integrate with Facebook, we will need some form of HTTP server, so that we can run our application from an http://-based URL, rather than simply launching a file from a local folder on your computer. Ideally we need a live, publicly-accessible domain under our control, and we'll configure our Facebook Application to use pages on that domain as the basis for our Canvas and Tab applications.
In addition, if we can, it would be most efficient (but not essential) to have an HTTP server set up on our local machine—allowing us to test and debug our Flash Player applications locally, without having to re-upload files to a remote site every time we need to test new functionality.
1 The first thing we'll need is a web-based Flash Player application, which we can get by specifying Web (runs in Adobe Flash Player) when we create our Flex project:
2. Open the folder in your project named html-template. If that folder doesn't exist, open your project settings, and make sure that the option Generate HTML wrapper file under the Flex compiler section is checked.
Note
Downloading the example code for this book
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
3. The first change we're going to make to our file is to import the Facebook JavaScript SDK. Into the head section of the HTML page (between the opening
<head>and closing</head>tags) add the following code:<script type="text/javascript" src="http://connect.facebook.net/en_US/all.js"></script>
4. This script tag imports the JavaScript SDK into our HTML page, but to activate it we need to add a specific HTML element—a div element with a specific ID. Jump to the bottom of the page, before the penultimate closing tag,
</body>, and add a new DIV element, with the ID of fb-root:<div id="fb-root"></div>
5. With these additions, our final HTML code for the entire page template should be similar to this (with our additions to the HTML highlighted):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- saved from url=(0014)about:internet --> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>${title}</title> <style type="text/css" media="screen"> html, body { height:100%; } body { margin:0; padding:0; overflow:auto; text-align:center; background-color: ${bgcolor}; } #flashContent { display:none; } </style> <script type="text/javascript" src="swfobject.js"></script> <script type="text/javascript"> var swfVersionStr = "${version_major}.${version_minor}.${version_revision}"; var xiSwfUrlStr = "${expressInstallSwf}"; var flashvars = {}; var params = {}; params.quality = "high"; params.bgcolor = "${bgcolor}"; params.allowscriptaccess = "sameDomain"; params.allowfullscreen = "true"; var attributes = {}; attributes.id = "${application}"; attributes.name = "${application}"; attributes.align = "middle"; swfobject.embedSWF( "${swf}.swf", "flashContent", "${width}", "${height}", swfVersionStr, xiSwfUrlStr, flashvars, params, attributes); swfobject.createCSS("#flashContent", "display:block;text-align:left;"); </script> <script type="text/javascript" src="http://connect.facebook.net/en_US/all.js"></script> </head> <body> <div id="flashContent"> <p>To view this page ensure that Adobe Flash Player version ${version_major}.${version_minor}. ${version_revision} or greater is installed.</p> </div> <div id="fb-root"> </div> </body> </html>6. These additions are all we need to attempt communication with the Graph API from a technical point of view, but before our API requests are successful, we must make sure that our application is configured correctly on Facebook.com.
8. Edit our existing application, and switch the Web Site tab, which contains two key fields—Site URL and Site Domain:
9. Our Site URL will be the location of our application when we upload it to a publicly-accessible HTTP server, and should be expressed as an URL (starting with
http://).10. The Site Domain (expressed without the
http://prefix) allows us to control the domain and subdomains that are allowed to access the Graph API, while identifying as our application. Once this property is set, only requests that appear to come from that specified URL (or part URL) will be allowed to make requests, and all others will be summarily rejected by the Graph API with the error message:Given URL is not allowed by the Application configuration.
11. Change the Site URL property to point at our Flash application's live location, such as: http://facebook.psyked.co.uk/packt/.
12. Change the Site Domain property so that it lists the main domain of our application's live location, for example: psyked.co.uk.
13. Now, with the Site's URL and Domain settings established, our next step should be to upload our application and its HTML files to the location we've specified in the Site URL field. Once those files are uploaded and available from the domain we specified in the Site Domain field, we should see no more of those Given URL is not allowed... errors.
14. Finally, to test our application we will need to upload our HTML and SWF files to a live web server—one that is able to serve up our application's HTML file from within the domain that we specified in the Site Domain setting in the Facebook Developer center. For example,
http://psyked.co.uk/packt/Facebook.html.
The web-based version of the Facebook ActionScript 3 SDK has been developed with a reliance on the Facebook JavaScript SDK being included in the containing HTML page—hence the requirement for us to extend our HTML template to incorporate this SDK.
When we add the script tag to our HTML template—using the URL http://connect.facebook.net/en_US/all.js as the source location—we are importing the Facebook JavaScript SDK from the Facebook.com servers. There are a few fringe benefits to loading the JavaScript SDK in this way—it keeps the SDK up-to-date and it helps with caching resources, but the primary reason for loading the SDK from the Facebook.com domain, rather than downloading it and packaging it alongside the HTML and SWF files on our own servers, is that this avoids a lot of potential for cross-domain scripting issues, and makes domain-restricted information such as cookies available to our application.
The addition of an HTML element with an ID of fb-root is part of the basic requirements for the JavaScript SDK, which are also discussed in more detail in the Facebook Developer documentation:
http://developers.facebook.com/docs/reference/javascript/
In short, the JavaScript SDK needs an actual element on the HTML page to hook into, and that element is one with an ID of fb-root—which is hardcoded into the SDK itself.
What we've done is in this recipe is simply to set up our project so that it will be able to work with the Facebook APIs, when it's uploaded to the domain that we've specified for our application, in the applications' settings, in the Facebook Developer center.
The Graph API automatically rejects requests that use our Application's API Key if those requests come from a domain other than the domain specified by the Site URL and Site Domain settings—which means that if we try to test our code using URLS like:
C:\Workspace\Facebook Example\bin-debug\Facebook.html
or
file://Users/Admin/Workspace/Facebook Example/bin-debug/Facebook.html
the Graph API would automatically reject requests originating from those URLs, because they're not on the domain specified in our Facebook Application settings.
In actual fact, trying to work with these URLs would likely throw a Security Sandbox Error from the Flash Player before things even got to the point of communicating with the Graph API. The ideal setup to avoid this is instead to have a HTTP server running locally that can deliver these same HTML files, but from an http:// protocol, such as:
http://localhost/Facebook%20Example/bin-debug/Facebook.html
This would avoid any Flash Player security issues, but requests to the Graph API would still be rejected, because the domain, localhost, is not the same as the domain specified in our application settings (in my case, psyked.co.uk).
To develop efficiently for Facebook, we should expect to be able to code and test frequently, without the constant need to upload and re-upload our Flash application to a remote domain, yet still have everything work as if our application were online at the domain outlined in the Site Domain setting we previously specified.
Note
To test our application locally, we must have an HTTP server installed and running on our computer, something like the Apache HTTP Server, which is available from: http://httpd.apache.org/.
Support for server-side languages isn't important for our needs—all we require is the ability to launch our Flash Player application from an http://-based URL, rather than a local or network path.
There are two approaches we can take to get a Project that we have running locally to work with the Graph API:
1. Adjust the Site Domain project setting to work exclusively with the domain
localhost.or
2. Use setup a subdomain (such as
localhost.psyked.co.uk) on our live website domain that points at our local machine.
Either of these solutions is valid—they both conspire to ensure that the Site Domain in our Facebook Application settings and the current URL that we're viewing match up.
If we choose the first option—adjusting our Site Domain property to say localhost—it should allow our local machine to work with Facebook, but at the cost of our live, publicly-accessible website not being able to communicate with the Graph API. Of course, that doesn't preclude us from setting up more than one Facebook application—a local development and live deployment application, if necessary.
The other alternative—using a subdomain—assumes that we can manage our top-level domain and create entries for new subdomains. All that is actually required for domain validation with the Graph API is that the computer on which the code is running believes that it is running on a specific domain—not that the domain is actually valid, or even that the domain even exists.
Thus we could create a new subdomain on our live website, such as localhost.psyked.co.uk, and have it point at the IP Address 127.0.0.1. For users without an HTTP server installed, they'll see nothing, and for developers like us, we'll see our own local HTTP server.
With our allowed domain effectively being *.psyked.co.uk the requests from localhost.psyked.co.uk will be accepted by the Graph API, and we can test our code much faster.
There are (currently) three main kinds of Facebook-enabled applications. These are:
This categorization represents the route by which users discover our application, as much as anything else. From a technical perspective, our application is always an HTML page, with a Flash Player application nested inside.
Canvas and Page Tab applications are actually HTML iframe elements on the Facebook.com website—they appear within the normal Facebook website interface, but the content that's being displayed comes from your own web server, and the same content is technically available from outside those iframe elements, if you have a direct link.
For example, we can have a Canvas application accessible from the URL:
http://apps.facebook.com/packt_facebook/
But the HTML source for this Canvas application is actually located at the URL:
http://facebook.psyked.co.uk/packt/
The integration of these two separate websites is seamless for the end user, but the context of each places different constraints on our application in terms of the dimensions of the application.
To set up our application so that it appears within the Facebook.com website as a Canvas or Page Tab we need to visit the Facebook Developer center and edit the settings of our Facebook Application, which we can do via the URL:
http://www.facebook.com/developers/apps.php
Select an application, click Edit settings, and then go to the Facebook Integration section, where you can make specific entries for the Canvas URL and Tab URL parameters—choosing exact URLs that point to an HTML page that would be formatted correctly for the dimensions of the iframes. Canvas applications are 760 pixels wide and Tab applications are only 520 pixels wide.
Not every application has to be a Canvas or Page Tab application, however. It doesn't even have to be an application on Facebook—it can just be one that interacts with Facebook, so long as our Flash application remains within the Site Domain boundaries we've specified in the Facebook Developer center.
If you are adding Flash elements to a Facebook application you've already developed in a server-side language, then you may find that you don't need to worry about adding additional JavaScript files to the mix.
Say for example you've already developed a Facebook login process; using Facebook's own PHP SDK, you could simply forget about including the JavaScript SDK and instead use FlashVars to pass in the session data and authorization tokens at the point the page is generated. Not only would you not need to load an additional JavaScript file, but you'd also not have to make duplicate session requests with Facebook, which should speed things up a little.
The key point is that Facebook cannot always know—and doesn't really care—how you're making requests to its APIs, only that you do so with valid authorization tokens and request parameters.