From Facebook Developers Wiki

This article is being flagged for cleanup. Reason: This page could probably use some cleaning up. - The Dept. of Redundancy Department - Discuss

The callback page is the page Facebook calls whenever it needs to notify your app of something or get the content of the canvas page for your app. (Not all content is retrieved this way. To put content on profile pages, for example, you push it to Facebook rather than having it pulled via callback. See Basic application architecture for more.)

The callback page now does, theoretically, double-duty. In the previous world of the Facebook API, your callback page would get called back when the user visited login.php, and it would be a GET with a &auth_token= (and whatever else you wanted to pass around).

If, however, the user visits apps.facebook.com/yourapphere/, then the callback is called to serve the "canvas". In that case, it gets a POST. The post always has the following four fields:

• fb_sig_in_canvas (1/0, is this a request for a canvas page?)
• fb_sig_added (1/0, has this application been added)
• fb_sig_time (current time, float seconds since epoch)
• fb_sig_api_key (you should know this one)
• fb_sig (a signature of the request for validating the request actually came from facebook, the same as for submitting to the API (see auth for details or some PHP example-code), but keys should not be prefixed with fb_sig_ - that is, both for submitting a request to the API the values shouldn't have fb_sig_ but also for verifying a Facebook request to your canvas page [Facebook will request your page with the values including fb_sig_ and you need to remove fb_sig_ from the keys before hashing them to verify the signature]).

If the user is logged in to Facebook, and has "granted access" to your app, then you'll get these additional fields:

• fb_sig_user (uid)
• fb_sig_friends (comma separated list of uids)
• fb_sig_session_key (session key)
• fb_sig_expires (int, 0 if this key never expires, or expiration time (in seconds since epoch) if it does)
• fb_sig_profile_update_time (int, seconds since epoch)

(See Bug# 107. On some occassions you do not get these fields when the user has logged on to Facebook even though they may have "granted access" to your app when they installed it. Does anyone have a work-around for this problem?)

One workaround is not to use Facebook's generate/verify API. You can pick a good set of parameters like session key, user id, and maybe a random GUID and generate your own signature key on the form using MD5. Use your own verify method that uses the same set of parameters on the server side. One nice thing about doing it this way is your pages won't break once Facebook chooses to add/remove some parameters from their signature generation. -- Rob

Thus there are technically four states you might serve a canvas page in:

• The user is not logged in to Facebook. (**Expand on this. If I try and access a canvas page (apps.facebook.com/myapp) without being logged in I am prompted to log in, therefore is this state actually possible?) - No, just remove this line: $user_id = $facebook->require_login();
• The user is logged in to Facebook, but has not "granted access" to your application.
• The user is logged in to Facebook, and has "granted access" to your application, but hasn't "added" your app.
• The user is logged in to Facebook, and has "granted access" and "added" your application.

(Note that you cannot tell the difference between the first two of these.)

When any user installs your app, the following parameter is passed to your callback page via GET:

• installed=1
• auth_token=(some value)

If you use the callback as a canvas (as you likely will), make sure to append a slash to the end of it, as the remainder of the URL will be appended right after the canvas to form your iframe URL.

Questions How do the four states correlate with fb_sig_expires ? I'm guessing:

• The user is not logged in to Facebook.

> 0

• The user is logged in to Facebook, but has not "granted access" to your application.

> 0

• The user is logged in to Facebook, and has "granted access" to your application, but hasn't "added" your app.

> 0

• The user is logged in to Facebook, and has "granted access" and "added" your application.

0

If anyone could give some more info about authentication and infinite sessions as they relate to f8/internal facebook apps, that would be awesome. Read more about infinite sessions and Infinite session keys.