Accessing User Information with Your Applications

We've received a lot of feedback ever since we announced that we're changing how users authorize applications. Since we offered more details last week, we've made additional changes to make this even simpler and better for both users and developers, by allowing access to basic user information while maintaining user choice and control. These changes will be available later today (Monday) in the sandbox.

Users have always been able to interact with your application's canvas page without logging in to or adding your application. Now, when a user who has opted in to the new profile actively chooses to visit your application's canvas page from Facebook, we'll allow your application to call for information about the user and her friends that they've made available in public search listings, namely the UID, profile picture, and name of the viewing user and the UIDs of her friends. Access to this information is subject to the Facebook Platform Terms of Service, and this information is not provided for any user who decided to completely opt out of Facebook Platform or whose profiles aren't publicly searchable). When the user is on your canvas page, the user can also use Feed forms and request forms, because they require user approval. The user can interact with your application in the Publisher on a friend's profile. You can publish one line stories with the user's approval. If a user changes her privacy settings, then her information is no longer available.

On the canvas page you can prompt the user to allow your application to access more information and ask for additional permissions. This is essentially the same as what we earlier announced as authorizing an application, but now the experience is even more lightweight -- see the sample login dialog to your right. This Ajax dialog replaces the current add page and the login screen you saw in earlier posts.

Once the user allows access, you can start sending notifications; publishing short and full stories with user approval, and one line stories without approval; accessing the user's profile data and setting FBML (though the user has to approve any box). You can prompt the user for extended permissions, like granting offline access to your application, the ability to send email, or updating status (note: offline access replaces the concept of an "infinite session").

A user only has go to through this experience once to allow access for your application. The application will appear in the user’s list of all applications, where the user can remove access at any time.

When the user allows access, we'll ping your application (at what's now known as a post-authorization URL) with a callback to let you know that the user has allowed your application to access her data. You can also redirect the user (using a post-authorization redirect URL) if you need to take the user somewhere else.

We'll also grant your application a temporary session key that lasts up to one hour after the user stops interacting with your application, or until the user logs out of Facebook (in which case, the session ends immediately). When that user interacts with your application, or visits the canvas page, we'll renew the session key. We'll keep renewing the session key as long as the user keeps interacting.

Users who have previously added your application will be migrated to temporary sessions by August 15th. During the user preview period you will receive temporary sessions for all new users of your application who have opted into the new profile. After the preview period ends, all new application users will receive temporary sessions.

In addition, a user can grant a permanent session key for use in your application. You can prompt the user to grant your application offline access using the fb:prompt-permission FBML tag and the promptpermission attribute.

If the user explicitly grants your application offline access, then you can continue to use that key for this user. There are two ways a user can deny offline access after they've granted it; by revoking the extended permission from the application, or by removing the application. Removing an application also removes the application's integration points and all permissions.

Don't forget: Since we are eventually going to deprecate add.php, change those require_add calls to require_login. We're redirecting any calls to add.php to login.php. The exception is for the case of a user adding an application to a Facebook Page, in which case add.php will still function like it does today.

Contacting Us

We continue to want to hear from you about the new design and your experiences trying it out. Please report any bugs you see in the new design. Make sure you use the New Profile category. You can help us solve your issue faster by adding one of the following components to your report: Feed, Info Sections, Profile Boxes, Publisher, and Tabs.

You can send us your feedback and ask questions in the New Profile and Related Changes section of the Developer Forum.