Shannon Whitley

I think I first read about the new Facebook Javascript API on Techcrunch: 

I’m not sure anyone saw this move coming, but Facebook may have just changed the game again by essentially becoming an application host. It’s a clever move by Facebook in a year its competitors will get more serious about offering platforms themselves.

  The announcement was followed by several articles, blog posts, hundreds of comments, and Twitter discussions.  I even wrote a quick post on some of the confusion that resulted from the announcement, basically trying to dispel the myth that every Facebook app could now instantly become a widget.

A few weeks later, I finally had time to take a look at the API.  Most of the functionality that I needed is in the sample code provided on the developer’s wiki.  I implemented the code and everything seemed to work.  I setup my application and tested the process.  As advertised, I was forced to login to Facebook before I could access my application.  Once I went through Facebook’s signon process, I was sent back to my application and I was able to retrieve my Facebook user id in the application code.  Easy!

Next step, I began testing the application more thoroughly to ensure there weren’t any holes in the process.  Facebook returns several additional querystring variables to my application.  One of the variables contains my Facebook user id.  I changed that value in my browser’s address bar to a different user id and updated my application page.  I shouldn’t be able to do this, but rather than producing an error or ignoring the user id that I had typed, the Facebook code returned the altered uid.  With the current code, I could login to my application with someone else’s user id.  Not good.

I should note that I’m not trying to skewer the Facebook developer here.  I’ve looked at the API code and I think it’s First Rate.  I just want to highlight this issue to prevent other developers from making big mistakes with their app security.

api.get_session().uid returned the correct Facebook uid following the authentication process, however, I was able to change the uid value in the querystring.  api.get_session().uid then returned the new value.  Bottom line:  you can’t rely on api.get_session().uid without some additional checks.

I asked around for a process to help verify the uid.  No response.

I went back to the basics and tried implementing Facebook’s sample code.  I found that a javascript error in the base API is preventing me from any further testing.

I’ve filed a bug report and contacted the developer.  The developer has already responded to me, and I know he’s looking at the issue.  These things happen, and I’m sure we’ll figure it out soon.

What really interests me is not the tech part of these issues, it’s the disconnect between the marketing and the actual implementation.  This announcement was a pretty big deal back in January.  Hundreds of people wrote about it.  I would have thought that at least someone had implemented it, or at least tried, by now.

I went to the Official Facebook Developer’s Discussion Board and asked for anyone to identify themselves if they’ve implemented the Javascript API.  One person mentioned that they had also tried and failed.

I’m looking forward to using this product.  I think it’s a great addition to the Facebook platform.  I just wish there were fewer people talking about these tools and more actually working with them.

 

[Update]

The technical problem has been solved.  The API was changed, but the sample code was not up-to-date.  There is a new parameter in the code, “flid” — you can pass in null and it works:

api.friends_get(null, function(result, exception) {});

 

There is still an issue with api.get_session().uid — I recommend using the following function instead:

api.users_getLoggedInUser(function(result, exception) {});

This function always retrieves the correct uid, and returns null if the session was altered in the querystring.