Much scrutiny of late was directed at the social media giant’s security policies (or rather, lack thereof), and Facebook responded by stepping up their approach on security, at least as far as extended permissions go.
Let’s take a step back. In the past, users, by connecting to an application, allowed Facebook applications access to an implicitly specified amount of their profile information. Now users are confronted with an explicit list of permissions the Application is asking for.
Of course, change is always opposed by proponents of the status quo, and the reception of Facebook’s decision to try and sort out their permissions policy is no exception.
The change has caused waves of dispair in the Facebook developer community, especially amongst members of the DIY mashup community. For instance, click here to see what a search for “extended permissions” on the Facebook Developers Forum typically returns: Click here
marcgg: “I am having quite a big issue. Last week and without any changes on my end my application (that was working fine until then) couldn’t ask for the extended permissions “publish_stream”. Since I need it to upload photos and other things in a page stream this was a problem.”
kanarinkabot: “My app requests extended permissions for a user’s email address however I can’t figure out how to retrieve the email address using the graph API.”
neerou: “I am currently working on a J2EE application which fetch user data from facebook after the latter has granted the necessary extended permissions. I have an issue regarding the email. My application has to send confirmation emails later to notify users of transaction completion. From the login dialog before the user grant the permissions, they have options to change the email and use an anonymous email instead of their real email address.”
sofiadavis1: “I am also finding like wise same stuff and Which method is the best/most convenient if i want to implement Facebook authentication with extended permissions using Google app engine and Django But I am confused if any have more idea about this then please mention here.”
While the extended permissions clearly proves to be a stumbling block to many developers, it is actually one of the few well designed aspects of Facebook’s suite of API’s. (no, I’m not generally a fan of the Facebook API, quite the contrary)
Ease of Use
A comma-seperated list of extended permissions is passed as a GET variable to the Facebook login URL, redirected to when getting the user to log in. It couldn’t be more simple. For some bizarre reason, though, Facebook decided to use different variable names for the graph API and the normal API. And, as usual with Facebook, this “feature” is extremely poorly documented. For your own reference, it’s scope in the graph API, en req_perms in the normal API.
Clarity of Permission Names
Permission names are simple and self-explanatory; you don’t have to consult the list time and again to remember them. email, for instance, gives you access to the user’s email address. publish_stream allows you to publish to a users stream, and read_stream allows you to (guess what!) read from a user’s stream.
User Friendly Dialog Descriptions
The way each permission is translated to the user in the connection dialog is also simple, complete, and makes perfect sense. It’s amazing how often big software companies fumble with this step. For instance, read_stream is translated to the user as Access posts in my news feed. Pretty self-explanatory, huh?.
Next Week: Some security concerns, and the silver lining.
Posted by Adriaan Pelzer