So this is new. And by new I mean painfully similar to the types of major functionality bugs we see every time there is a large-scale functionality change in Facebook.
I don’t know if this is a bug, or just undocumented, but I am unable to get the FBID of a user (even one who has allowed and interacted with the app) if the application is on its own tab in a fan page. I can get it on the boxes tab (by way of a workaround below) or on its own canvas page, but nothing works for the application tab.
Part of one of the recent changes to the platform was that you could no longer use require_login() from a tab (boxes or application). You can still use it on the application’s canvas page, but when you try to use require_login() in a tab, you’ll get an error that tells you you cannot redirect, something like:
fb:redirect: redirect forbidden by flavor TabFBMLFlavor
A suggestion on the developer forums suggests using:
[source=’php’]$is_tab = isset($_POST[‘fb_sig_in_profile_tab’]);
if( !$is_tab ) $user = $fb->require_login();[/source]
This basically checks to see if the application is being accessed via a tab (versus the canvas page or profile box). If it is being accessed via a tab, use the $_POST[‘fb_sig_in_profile_tab’], and if not, go ahead with require_login() as usual.
The problem is, while this works on profile tabs, it does NOT work on fan page tabs. When you use $_POST[‘fb_sig_in_profile_tab’] in an application on a fan page tab (or any of the other non-require_login() methods of getting a user’s ID) you end up with the ID of the fan page, NOT the viewing user.
This is a major problem for me, as many of the applications I have to build are not meant for addition to the directory, but are instead meant to be used only on a corporation’s fan page. The inability to access the user’s FBID severely limits what that application can do. In fact, it more often than not renders it completely useless.
To work around this, you can use the following to get the FBID of a user when your application is appearing in the Boxes tab:
[source=’php’]function get_user() {global $facebook;
global $authorized;
$authorized=true;
// this will fail if user hasn’t authorized:
try { return $facebook->api_client->users_getLoggedInUser(); }
$authorized=false;
return $facebook->get_canvas_user()
}[/source]
and then setting the $user FBID variable with:
[source=’php’]$user = get_user();[/source]However, even this does not work on applications appear in their own tab on a fan page.
I downloaded Facebook’s sample application, “Smiley”, to attempt to see how they did it. I’m certainly not new to Facebook application development, but I figured using their own code would help me see how they handle this particular issue.
I, of course, made the gross assumption that their own sample application would be updated with the most recent API calls and best practices. Not only is the Smiley’s app not up to date with the most recent ApI changes, it is flat-out *broken*. Thanks to several files that are completely *missing*, Smiley’s doesn’t even run. The very first line of the index.php makes an include call to a file called constants.php that DOES NOT EXIST. Well done, as usual, Facebook. The new API changes have been out for weeks now – there is just no excuse foer the ongoing broken samples and stubbed or missing documentation.
I have spoken to Facebook and they insist that this was a policy decision to prevent applications from spamming users – however there are a few problems with this explanation:
- The FB user’s decide what applications can message them, email them, etc – and by blocking an app, they never hear from them again anyway. Application behavior is irrelevant.
- If they were concerned with spamming, why does this behavior only emerge when the app is on its own tab? Its okay to spam from Boxes and canvas then?
- If the user has allowed the application, they have voluntarily given the app their information.
- Disallowing applications from accessing the FBID of users who have allowed the application renders many applications completely useless. They’re basically statis HTML pages, and it seems unlikely that Facebook would so detrimentally cripple such an important part of the platform.
I suspect that I’m receiving inaccurate information from Facebook regarding this behavior, and I suspect this may be a bug. If this behavior was actually implemented to prevent applications from getting the FBID of users who have allowed it, the decision would have applied to Boxes as well.
I’m still going back and forth with Facebook on this, but I wanted to post it here in case other Facebook application developers are having the same trouble. When I discover the fix, I’ll post a followup here.
