views:

4182

answers:

3

I have a Facebook app that is built as an iFrame. I am using the JavaScript client API loaded via:

In my initialization code, I use the requireLogin method to ensure that the user has authorized the app. I have found this to be necessary to be able to gather the user's name, avatar, etc. for the scoreboard. Here's a representative code snippet:

FB_RequireFeatures(["Connect","Api"], function() {

    FB.Facebook.init("...API_KEY_HERE...", "xd_receiver.htm");

    var api = FB.Facebook.apiClient;
    api.requireLogin(function() {
        api.users_getInfo(
            FB.Connect.get_loggedInUser(),
            ["name", "pic_square", "profile_url"],
            function(users, ex) {
                /* use the data here */
            });
    });
});

This causes the iframe to redirect causing the Facebook authorization screen to load within my app's iFrame. This looks junky and is somewhat confusing to the user, e.g. there are two Facebook bars, etc.

Question 1: is there anything I can do to clean this up while still implementing as an iFrame, and still using the JavaScript APIs?

According to the FB API documentation:

FB.ApiClient.requireLogin

This method is deprecated - use FB.Connect.requireSession instead.

My experience though when I replace api.requireLogin with FB.Connect.requireSession it never gets invoked. I'd prefer the recommended way of doing it but I struggled and was not able to find a way to get it to work. I tried adding various arguments for the other two parameters as well with seemingly no effect. My expectation is that this method will load in a dialog box inside my app iFrame with a similar authorization message.

Question 2: what am I missing with getting FB.Connect.requireSession to properly prompt the user for authorization?

Finally, at the end of the game, the app prompts the user for the ability to publish their score to their stream via FB.Connect.streamPublish. Which leads me to...

Question 3: am I loading the correct features? Do I need both "Api" and "Connect"? Am I missing any others?

A: 

Question 1: is there anything I can do to clean this up while still implementing as an iFrame, and still using the JavaScript APIs?

Question 2: what am I missing with getting FB.Connect.requireSession to properly prompt the user for authorization?

Please have a look at this. This article discusses correct use of require session and provides links on how to implement that. And yes, you are right, the requireLogin has been deprecated and won't help any more.

Question 3: am I loading the correct features? Do I need both "Api" and "Connect"? Am I missing any others?

As far as I know, you can use both API and Connect together, basically you access facebook's api with the help of javascript.

For iframe apps however, there is no great help and minimum support of API with some handful funtionality available. See this for more info..

This causes the iframe to redirect causing the Facebook authorization screen to load within my app's iFrame. This looks junky and is somewhat confusing to the user, e.g. there are two Facebook bars, etc.

Finally and personally I have not seen any iframe app requiring user to add the app first. This will create the problem of two bars you mentioned as quoted above.

The link I posted at the beginning of my answer has some useful links to get you started and decide the next-steps or possibly making changes to your apps.

Thanks and hope that helps :)

Sarfraz
I tried using FBConnect authorization but it was a strange experience of popup windows and FBConnect buttons. That style of authentication / authorization works much better on a completely external site. For iFrames, the solution was ultimately to redirect to the login URL which becomes the authorization URL if they are not already logged in.
McKAMEY
A: 

I think that FB.requireSession only works from a FB connect site outside of Facebook. If you're using an app hosted on apps.facebook.com use the php api call instead,

$facebook = new Facebook($appapikey, $appsecret); $facebook->require_login();

or link to the login page.

Of these methods to login

*  Using the PHP client library
* Directing users to login.php
* Including the requirelogin attribute in a link or form
* Using FBML 

only the first 2 are available to iframe apps hosted on apps.facebook.com

I think requirelogin and fbml only work with fbml canvas apps.

see http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Canvas_Page_Applications_on_Facebook

alex
I am not developing in PHP, so their client library doesn't do my any good. The tip about redirecting to the Login page was ultimately what solved my issue. For others reading this, XFBML and API calls work fine in iFrame apps.
McKAMEY
+1  A: 

Here is a summary of the changes I needed to make to clean up the authorization process. It appears that iFrames must fully redirect to properly authorize. I tried using the FBConnect authorization but it was a strange experience of popup windows and FBConnect buttons.

Ultimately this game me the expected experience that I've seen with other FB apps:

FB_RequireFeatures(["Connect","Api"], function() {
    var apiKey = "...",
        canvasUrl = "http://apps.facebook.com/...";

    function authRedirect() {
        // need to break out of iFrame
        window.top.location.href = "http://www.facebook.com/login.php?v=1.0&api_key="+encodeURIComponent(apiKey)+"&next="+encodeURIComponent(canvasUrl)+"&canvas=";
    }

    FB.Facebook.init(apiKey, "xd_receiver.htm");

    FB.ensureInit(function() {
        FB.Connect.ifUserConnected(
            function() {
                var uid = FB.Connect.get_loggedInUser();
                if (!uid) {
                    authRedirect();
                    return;
                }

                FB.Facebook.apiClient.users_getInfo(
                    uid,
                    ["name", "pic_square", "profile_url"],
                    function(users, ex) {
                        /* user the data here */
                    });
            },
            authRedirect);
});

For iFrames, the solution was ultimately to redirect to the login URL which becomes the authorization URL if they are not already logged in.

McKAMEY

related questions