Facebook for Developers: Canvas & Connect

The Facebook development platform consists of two implementation variations: Canvas (FBML) and Facebook Connect (XFBML). Depending on the set goal for what you are trying to accomplish, one might supersede the other.

Facebook’s Canvas Pages

Canvas Pages work the same as a typical Web page. They appear inside of Facebook.com and can contain just about any content. With Canvas Pages, you can have an unlimited number of pages, which can link to one another and are hosted on a remote server. The creation of Canvas Pages consists of a Facebook Markup Language called FBML, which is similar to HTML.

When creating a Canvas Page with Drupal, you run into a few issues:

The solution to these issues is to produce FBML at the theme layer and have the URLs map on a one-to-one ratio. Start by building out your theme using FBML. As for the URL, use the rewrite to do a one-to-one URL. For instance, http://example.com/hello is the equivalent to http://apps.facebook.com/hello and they are handled by the same callback functions. The next step is to allow the sessions to be controlled by Facebook using fb_settings.php and including it in to your theme.

So the process for Canvas Pages are as follows:

user>FB>server (FBML)>FB(HTML)>user

Here is a brief summary for Facebook’s Canvas:


  • Develop Canvas Pages just as you would a Web page
  • Enable HTML and FBML themes
  • Administer your application on example.com/admin
  • Customize your FBML theme



  • Reinvent the wheel
  • Code logic into your theme
  • Assume javascript will work (use FBJS or FBJQUI)


Facebook Connect

Facebook Connect brings social features to your website. Drupal for Facebook supports Facebook Connect, as well. Facebook Connect connects to Facebook.com, as well as all other Facebook Connect websites. This saves the trouble of logging in multiple times to authorizing the application.

Facebook Connect uses XFBML, which adds features to your site. For instance, you can show features of Facebook such as walls, comment forms, friend lists, pop-ups and everything else that Facebook has to offer directly on your website.

To develop a Facebook Connect Page, create it on Facebook as an application. Once you have done that, grab the API and enter it in the Drupal Facebook Module. Once set up, you create your theme by using XFBML. Once you have done so, your process is as follows:

User>Server(XFBML)>User XSS>FB(HTML)>User

Once your Facebook Connect Page is created, you can then take advantage of everything Facebook has to offer. Remember to read its disclaimer policy because Facebook has rules on what can and cannot be used.

One of the cool aspects of using Facebook Connect vs. Canvas is that you can do instant anonymous/authorized registration. Which then will create a local account and authmap automatically. This can be tricky, but you can use the caveat $user->name and $user->mail. And by doing this, you avoid duplicated accounts.

For Support:



Facebook Development


Top Five Ways Developers can Abuse Drupal

Drupal is a widely popular open source content management system (CMS). It’s powering big name sites, including WhiteHouse.gov, AOL Corporate, AT&T, CNN, Fast Company and so on. With such a wide following, it is easy for developers to abuse the platform in several ways. And they do.

Here are the top five ways Drupal is typically abused:

  1. 1.  XSS – Cross-Site Scripting
  2. 2.  Access Bypass
  3. 3.  CSRF
  4. 4.  SQL Injection
  5. 5.  Code execution

    One of the best practices when it comes to Drupal development is to use the Drupal API. Follow what core is doing. Most of the approaches Drupal’s API/core take are safe and recommended by the Drupal Security community. The Drupal API will prevent XSS by checking and sanitizing the values.

    As a Themer, you want to follow default implementations. Don’t place functions or scripts inside the template. Instead, rely on the module developers for supplying the variables. Typically if the module developers are following Drupal best practices, then you can assume that you are safe. The general idea is that the developers will be the key holders to the data severed.

    As a Developer, you have to ask yourself some major questions about the information you are working with.

    • Where does it originate from?
    • Is there a way the user can change it?
    • What context is it being used?

    Typically the process is as follows:

    User > Drupal > MySQL > Drupal > User

    A good rule of thumb as a Developer is to mimic how Core serves data. By following the Drupal Core practices, you will have stronger protection against the site being cracked.

    The context of how the data is served will determine the process you serve it back to the user.

    For more information visit:



    Cross-site request forgery is the second most common problem in Drupal (taking actions without confirming intent, AKA CSRF). For instance, a user can be deleted via an URL by interjecting the server request in an image tag. To prevent such an injection, set the input format filter and use tokens for links. By setting the input format filter, you can control the user’s ability to create or call images, JavaScript, PHP, etc. The preferred practice is to not let the user create such things. By allowing users to create such elements you are jeopardizing your site for interjections. With a token added to the end of an URL, you can prevent an interjection by using drupal_get_token(‘myid’) and drupal_valid_token($GET[‘token’],’myid’). Another good practice is to always use Drupal’s Form API because it automatically uses tokens.

    The great thing about Drupal is it’s extremely large, and helpful community, which is constantly checking severalties and other vulnerabilities.

    Severalties and other vulnerabilities can be viewed here:


    You will see a lot of other categories of vulnerabilities in addition to XSS and CSRF.

    You can also see what possible risks you might have by using certain modules at the following URL:


    Author’s note: a good rule of thumb is if there is no fix, disable.

    The most typical ways your site is abused is by arbitrary code execution, SQL interjection, access bypassing and directory traversal.

    Arbitrary Code Execution

    This usually means some site user may be able to run PHP commands, or PHP in a file (a log file) may be included and executed. The most obvious, though sometimes overlooked, solution is allowing users to use the PHP input format. Recent examples include uses of preg_replace() where the result of the regular expression match could be executed as PHP.

    SQL Injection

    User input is added directly to the SQL that is sent to the database. In some cases this can allow users to delete or alter anything in the database (http://xkcd.com/327/). In other cases, it can reveal private information in the database – such as email addresses, hashed passwords, etc., which are used as the basis for further attack.

    Access Bypass

    This covers two problems: information disclosure and authentication bypass. Information disclosure: content is supposed to be protected, but isn’t. Authentication bypass: normal users can access an administrative page or operation.

    Directory Traversal

    The contents of a file chosen by the attacker can be included into the output. Typically this is when filenames are taken from the URL or other user input and characters links are not correctly escaped. This can reveal sensitive server information, your Drupal database credential, etc.

    Code execution possibility is the greatest danger.

    SQL injection + access bypass

    EX: BAD   = db_query_range(‘SELECT * FROM {node} n WHERE n.uid =’.arg(1), 0, 10);

    Good = db_query_range(‘db_rewrite_SQL(‘SELECT * FROM {node} n WHERE n.uid = %d AND published = 1’),  arg(1), 0, 10);



    Automating Drupal Website Configuration

    There is a common problem for website developers when starting a new project, performing the same meticulous configuration process over and over again, each time.

    This process includes:

    • Site installation and configuration
    • Module installation and configuration
    • Creation and settings for custom node types
    • Creation of taxonomy vocabularies and terms
    • Miscellaneous set up

    Luckily, there is a solution right out of the box that is heavily supported by the Drupal community: the combination of the Install Profile API and Features module.

    The Install Profile API is a set of helper functions (aka CRUD) that make it easier to work with Drupal data structures by providing some wrapper functions. This gives you the ability to create custom installation (Install Profiles). Using the Install Profile API with the Features API, we can further expand the installation and configuration capabilities.

    The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which, taken together, satisfy a certain use-case (ex: view a blog CCK to create a blog).

    Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically.

    In short, this combination of the Install Profiles API with the Features API gives you the ability to streamline the process of building a website in Drupal. For instance, you can have a custom installation profile, which includes a checkbox for the creation of a blog. And when you select that check box it auto generates a blog view, blog cck and a blog page.

    Watch a video from DrupalCon 2010, which I shot on this very subject: http://qik.com/video/6206554. (Note that the speaker is talking low during the entire session).