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:

Do(s):

  • 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

 

Don’t(s)

  • 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:

Drupal

 

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:

    http://acko.net/blog/safe-string-theory-for-the-web

    http://drupal.org/node/16489

    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:

    http://drupal.org/security/contrib

    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:

    http://drupal.org/security-team/risk-levels

    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);

    Resources:

    http://drupalsecurityreport.org
    http://drupal.org/security
    http://drupal.org/security-team
    http://drupal.org/security/secure-configuration
    http://drupal.org/writing-secure-code
    http://heine.familiedeelstra.com
    http://crackingdrupal.com

    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).

    Apache Solr: A Truly Advanced Search

    What is Apache Solr and how do you run it locally? How do you get Drupal data into Apache Solr?
    These are both questions you may have asked yourself at one time or another. Well, if you’re a developer at least. I hope to answer those questions as well as:

    •  How to search Apache Solr from Drupal
    •  How to modify what’s searched and the results
    •  Theming search results
    •  Fabulous-looking UI and tricks

    Apache Solr is an open-source, enterprise search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, and rich document (e.g., Word, PDF) handling. Solr is highly scalable, providing distributed search and index replication, and it powers the search and navigation features of many of the world’s largest Internet sites.

    With the Apache Solr module for Drupal, you can integrate Drupal with the Apache Solr search platform. Solr search can be used as a replacement for core content search and boasts both extra features and better performance. Among the extra features is the ability to have faceted searches ranging from content author to taxonomy to arbitrary CCK fields.

    Drupal interacts with Solr via HTTP and sends data to Solr as an XML. Solr accepts documents POSTed to / updated as well as an additional XML, if you want, for POSTed to /delete.

    The module comes with schema.xml and solrconfig.xml files which must be used in your Solr installation in order to get the module to work correctly. The schema defines the types and fields to be used.

    Example of a field:
    <field name =”” type=”string” index=”true” stored=”true” />

    •  Name the ID (required for indexing as the key identifier)
    •  Indexed = search it, if not indexed then it won’t be found.
    •  Stored = save data, if not, it won’t save.

    Example of Dynamic Field
    <dynamicField name=”is_*” type=”integer” indexed=”true” stored=”true” multiValued=”false” />
    multiValued = store multiple values, otherwise it’s a single value field

    To create a sortable version of the dynamic string field you use:
    <copyField sources=”ss_*” dest=”sort_ss_*” />

    By giving a “dynamicField” the name “nodeaccess,” you are declaring the permission for that field:

    In order to get rid of data that is not used, you can “ignore” it:t;>
    <dynamicField name =”*” type=”ignored” multiValued=”true” />

    This module depends on the search framework in the core. However, you may not want the core searches and only want Solr search. If that is the case, you want to use the Core Searches module in tandem with this module.

    If you’re looking for Solr PHP integration, this is possibly the best option available. This is also one of the best ways to achieve a faceted search. In addition, since you can shift the load of searches from PHP+SQL to a totally separate server, using Solr can help to scale Drupal for large, high-traffic sites.

    You can add any data to the index by using:
    hook_apachesolr_update_index($document, $node, $namespace).

    This is used to add more data to a doc before it is sent to Solr and can also be used to alter or replace data added by Apache Solr or another module. This works the same as _alter hook.

    If you want to exclude entire content types, you can just use the UI that is sent with the Apache Solr Module at this locatio n:
    /settings/apachesolr/admin

    The UI is the easiest way of implementation of Apache Solr and Drupal, but if you want a more precise indexing, you can control that with additional hooks.

    •  hook_apachesolr_node_exclude()
    •  hook_nodeapi()
    •  hook_apachesolr_document_handlers()

    For more on formation on this visit: http://evolvingweb.ca/story/apache-solr-mastery-how-add-custom-search-pa…

    To index CCK field information or Facet MIMIE type of CCK field, Solr needs 4 things:

    1. The data type to use in the index
    2. The CCK widget types to use during indexing
    3. An indexing CALLBACK function to be used for extracting the data from the CCK
    4. A display CALLBACK function to use for displaying the data from the CCK field.

    hook_apachesolr_cck_fields_alter parameter definitions:

    •  display_callback (optional)
    •  facet_block_callback (optional)
    •  index_type (required)
    •  indexing_callback (required)

    For more information on indexing CCK fields goto: http://drupal.org/node/776750

    See the documentation in the handbook as well as the included README.txt for information on requirements and installation.

    Drupal Page-Speed Optimization and Load Time

    A few tips for improving page-load-speed is to:
    • Run tests to track overall speed and see in what areas your site can improve
    • Make fewer HTTP requests
    • Use CDN
    • Increase front-end speed lt;/li>
    • Increase back-end speed
    • Use monitoring tools

    These subjects are extensive on their own, and will be only briefly covered in this article. For further and in-depth information visit: http://wimleers.com/article/improving-drupals-page-loading-performance.

    When testing a page’s load time, you will want to track every little nook and cranny. To track all of the HTTP requests, you can use http://webpagetest.org. The test will be conducted from the location specified, and you will be provided a waterfall diagram of your page’s load performance as well as a comparison against an optimization checklist. Please visit the PageTest wiki page for more information. (Sample results for AOL.com can be seen here.)

    You can also test the objects loading on your browser by using BrowserScope. BrowserScope is a community-driven project for profiling web browsers with goals of fostering innovation by tracking browser functionality and serving as a resource for web developers.

    Here are some free tools that you can use to evaluate the speed of your site:

    • Page Speed, an open source Firefox/Firebug add-on that evaluates the performance of web pages and gives suggestions for improvement.
    • YSlow, a free tool from Yahoo! that suggests ways to improve website speed.
    • WebPagetest shows a waterfall view of your page’s load performance plus an optimization checklist.
    • In Webmaster Tools, Labs > Site Performance shows the speed of your website as experienced by users around the world as in the chart below. We’ve also blogged about site performance.

    A good way to lower the number of HTTP requests is to take advantage of Drupal’s ability to compress CSS and JS files (through stripping comments and whitespace).  Host static content on different domains and use Googles Custom Search.

    A content delivery network, or content distribution network (CDN), is a system of computers containing copies of data placed at various points in a network to maximize bandwidth for access to the data from clients throughout the network. A client accesses a copy of the data important to said client, as opposed to all clients accessing the same central server, so as to avoid bottleneck near that server. You can use module SimpleCDN to do this on a Drupal installation.

    To increase Front- and Back-end speed, you will need to set the configurations for all your modules to an optimal setting. This means setting all of the performance modules in Drupal and in the server.

    Once the site has been optimized, you are going to want to monitor it. When monitoring, you want to check trend spotting, capacity and load, and review impacting changes. After checking, analyze the trends and find failures and up-times. If your site was running optimally, but a few months later you add a new feature to your site, monitoring will help you see how the new feature affected the overall performance.

    The rewards for page-load-speed are well worth the effort. By increasing your speed, you are more capable to serve your site to a host of people. Google actually encourages sites’ loading speeds by upping your rank in search relevancy when you have a fast-serving site.

    Tools are as listed:

    • Yslow for Firebug – Grades site based on Yahoo! best practices page speed – Firebug – Google (Steve Souders – overall performance summary)
    • webpagetest.orgBest for waterfall diagrams – talks to server, simulates connection speeds, browsers record visual representation of the page loading.
    • Apache Bench – impression of how your current Apache installation preforms, shows how many requests per second . ( Ab -n # -c # http://%5Bsite%5D/ )
    • Jmeter – load testing tool – log ssh, simulate authentic user
    • Devel Module – check query time, page and data ex time, checks views stats separately, authentic users
    • Parallels Module
    • Browserscope.org – Number of objects
    • Media Mover Module – performance module settings and how they work
    • Cache router – uses fast path settings, bypassing default cache use
    • Reverse proxy – advanced step: squid/varnish node/91813 – high performance range
    • Memcache Module – caches stuff in memory – uses pair values stored in memory – may live on other servers
    • Boost – extension of performance module – instead of caching results in table, stores them in files bypassing PHP and Mysql – limited to anonymous visitors – good for slashdot but not for sites with high number of authentic visitors – uses apache mod_rewrite directives to check if GET.  (retro mode)
    • BACKEND – PHP accelerator – APC is the alternative PHP cache, which is free, open and robust framework for caching and optimizing PHP intermediate code – Xcache and Accelerator are other options – Check configuration for proper memory settings.
    • MySQL Caching – Enable MySQL Query Cache and give it memory – index slow queries that run often – InnoDB Buffer Pool ++ ( Key_buffer is important for temp tables ) Core Search Runs better on MyISAM ( but don’t use Core Search )
    • apache – extend mod_espires settings
    • apache – deflate_module
    • apache – solution nginx – gzimp module
    • Nagios – monitoring tool

    For Support visit:

    http://wimleers.com/article/improving-drupals-page-loading-performance

    http://drupal.org/project/CDN/Simplecdn

    http://drupal.org/project/cdn

    http://twobits.com/
    (blogs about performance and security)

    Drupal Accessibility

    What is User Accessibility? The basic idea is that a website should have 100% user accessibility, which means they can use and interact with your site completely. In developing websites, we are strive for uniformity in all browsers, but rarely consider uniformity for all users. The truth is that 1:5 users has a disability and, in most cases, two or more types of disabilities.

    If these disabilities are not addressed during development, websites have the potential to lose 20% of potential users.

    The fundamentals of web accessibility standards are set by, but are not limited to, The W3C.

    The W3C documentation can be found at Web Accessibility Initiative (WAI). The current web content accessibility guidelines are located in a document at Web Content Accessibility Guidelines (WCAG) 2.0.

    When developing a website, you want to begin with the end in mind. Is the navigation accessible, user-friendly and self-explanatory? Do the CTA icons orient the user as to where they are in terms of the site frame work?

    The four rules for Creating a web accessible website (P.O.U.R.):

    • Perceivable – Is the content accessible? Screen Reader, Audio, Caption and Brail?
    • Operable – Can the user preform all the actions to navigate though the site?
    • Understandable – Does the user get confused with the web actions?
    • Robust – Will the interface be understandable, operable, and accessible in the future as technologies advance?

    A user can be deaf, blind, partially blind, color blind, partially color blind, and the list goes on. So, in order to make sure content is Perceivable, the site must be developed by keeping in mind the tools a visitor will use.

    Blind and partially blind users would use a Screen Reader (NVDA/Jaws/Thunders). These screen readers require HTML W3C compliance. Without the proper XHTML formatting/structure, these applications don’t function properly for users. For instance, improper use of heading tags, alt text, form and table structure, will cause confusion as in what they are supposedly perceiving. In the alt text, be descriptive and make the message user-friendly. For an example, an icon to purchase a ticket could read,” Purchase icon” or “Click here to buy icon”. One recommended practice for blind users is to create Skip Links (hidden anchors that can be used to skip to the top of a page to get back to the main navigation).

    With partial or full color blind users, it’s recommended to not use color cues because the user might not be able to notice them. In this case, text formatting cues like bold, border, or underline are more appropriate. Also be careful with link colors, since some users may not be able to identify the link.

    Recently, YouTube has pushed for closed captioning for deaf users. This is a huge deal when it comes to the hearing media files. One recommendation is to use a pointer to create text equivalents of audio files.

    People with disabilities sometimes use unique equipment to browse the web, such as keyboards with only basic keys (no cmd/Widow/Apple key) like arrow and enter, head wands or chin mouses. When developing a site we want to make sure we are not disabling or limited these tools. For instance, we don’t want to override the enter key on an online form. The enter key should be used to submit the form (default functionality).

    One of the best ways to create a user-friendly experience visitors with disabilities is by using WAI-ARIA. According to www.w3.org, “WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Currently certain functionality used in Web sites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges, for example, by defining new ways for functionality to be provided to assistive technology. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities”.

    The cool thing about Drupal is that it makes significant strides toward accessibility in version 6 and even further in version 7. Case in point, in Drupal 7 there are classes (element-invisible and element-hidden) that will hide content, but will be readable for users with disabilities via Screen Readers, brail or other applications.

    A good way to test your site for user accessibility is to screen users with disabilities. But if you can’t do that, the next best thing is to do a “squint-test”. This involves turning off all JavaScript, Flash, CSS, and unplugging your mouse, and then trying to navigate though your site. You can look at visual output checks with the VisChecks app. Also, the Fangs plugin for Firefox is a nice tool for checking Jaws publishing. Another good route is checking with W3C validators for XHTML.

    The Ultimate benefit from creating a disabilities-friendly site is more users, more traffic. That’s the ultimate goal, right?!

    Check out the chatter of Accessibility on IRC on Twitter. Just search drupal-accessibility