From Facebook Developer Wiki

This article presents a step-by-step guide for what you should think about when integrating Facebook Connect into your website.

For answers to specific questions like "Can I sell my user's info to everyone?", see the Platform Principles and Policies. (Short answer: No.)

Offer Users the Option to Connect

At its core, Facebook Connect is an alternative means of logging into a website. So, you should offer the option near your standard login flow. See Account Linking for details.

Citysearch puts the Connect button on the top, near Sign In:

Connect offers the most benefit to the user at the point where they want to create content to share with friends, or where they want to find out what their friends are doing on the site. So it’s good to also offer the Connect option close to those locations where users will want to use their Facebook account.  The WordPress plugin on TechCrunch puts the Connect button right next to the comment box:

Display the User's Facebook State on Your Site

Once a user has Connected, it's important that they don't feel lost. It's up to the website to provide them with an indicator that they are logged in with Facebook. This can be either a Facebook profile pic with the Facebook favicon ("f") in the corner, or even the phrase "You are logged in with Facebook" if it makes it more clear.

The Citysearch top bar lets the user know they are logged in with Facebook:

TechCrunch puts the state right next to the comment form. Users know they are logged in at the point of content creation.

The WordPress plugin by default offers the state in the top corner of the site, so it works across templates.


Auto-login and Auto-logout

Most Web software packages have their own concept of a user, separate from the login identity used to log in. This can create all sorts of unexpected or conflicting states. For example, what if the user is logged into Facebook but logged into WordPress using a different account?

Typically a simple way to solve this is to use auto-login. If the user is logged into Facebook with an account that has already connected, then just refresh the page and set the cookies locally so that they are connected. An easy way to do this is to call:

The corollary to auto-login is auto-logout. That means if the user clicks the logout link on your site, they should be logged out not only of your site but of Facebook as well. That is necessary, because if they aren't logged out of Facebook, then on the next page hit you'll log them right back in to your site.

This can be made more explicit with a "Log Out of Facebook" link if you prefer.

Storing User Data and Using XFBML

Many existing software systems have a concept of a user account. Facebook Connect is an alternate means of creating a user account. Your plugin should link the two accounts.

One restriction is that according the to Facebook Developer Terms of Service, an application can only store user data from Facebook for up to 24 hours. This is to make sure that if a user changes their data, it is refreshed across the Web, and the user does not see stale data as they browse. You can help users of your plugin obey this rule by fetching user data in one of three ways:

Fetch Fresh Data on Each Page Load

You can avoid pretty much all data storage issues by just doing an API call to Facebook for data on every page load. This is typically pretty easy, although it carries some performance and reliability issues. Notably, if a request to Facebook fails, then your users will not see their data.

Many of the top applications on Facebook as well as several Connect sites (such as Govit) use this approach.

Use XFBML

XFBML is a markup language that pushes data access to the client layer. It is the easiest for the programmer. It can also make pages more performant, by avoiding a round-trip to Facebook's servers, as would occur with an API call. With client-side caching, page loads with XFBML can also be just as fast as without.

For example, instead of fetching a user's profile picture, caching, and then refreshing the cache, you can just use this code once and it will always work:

Cache User Data in the Database

This is the trickiest of the three approaches, but it has advantages. Many websites already have the ability to store user data in a datastore. You can use this datastore, as long as you provide a way to flush the cache once a day. Typically this would by done by running a script in cron that refreshes cache.

If it's difficult to install a cron job (or you are writing a plugin and want to avoid installation overhead), then another way to do this is to trigger a cache flush on the first page request after X hours. This is a poor man's cron job. The Facebook-provided WordPress plugin uses this technique.

You can refresh data at the point you clear the cache. However, if the user is not logged in with an active session, then you'll need to use anonymous (logged-out) calls to fetch user data. This will fetch data that's publicly accessible.

Publish to News Feed

Whenever a user creates content, you want to make sure they publish that back to Facebook. Some example actions that merit publication include:

• Creating or replying to a forum post
• Creating or commenting on a blog post
• Creating a calendar item
• Posting a photo or photo album
• Creating an event
• Editing or publishing a wiki article

For each of these events, you will want to show an appropriate Feed form.

This means that your plugin will register a Feed template bundle ID when a user installs the plugin. This bundle ID will belong to that user's application.

Some sample code for doing this: