At the end of June, Facebook changed the way that applications request permission to access users' personal information. The change was good for users of Facebook applications,1 but it required application developers to make changes to their authentication process. Ignoring this change led to decreased functionality:
If your application has not upgraded to the new permissions scheme by June 30, it will be automatically upgraded. That means all new users will see the single authorization dialog, and your application will only be able to read the public parts of their profiles by default. [ed: emphasis mine]Since photographs are not public, this was a critical issue for my photo downloading Facebook application. Since I had failed to upgrade Photo Download to request "extended permissions," it stopped working.
However, due to the facts that previous users of the application were "grandfathered" into the new permissions structure (which meant that many users had no issues with the application) and that most new users did not choose to leave feedback (almost all who did gave the application a bad review, instead of emailing or contacting me to see if something was wrong), it was not immediately clear that anything was wrong.2 As a result, it took me an entire month to realize that all was not right.
My main concern at the time of discovery was the amount of effort that I was going to have to expend fixing this issue. I had constructed the original application using pyfacebook, which is not under active development and does not support Facebook's new Graph API or their new OAuth-based authentication methods. Facebook has released an official Python SDK, but because it is relatively new, there is a dearth of examples available online.
Because of this, I was initially unable to get authentication to work, even without implementing extended permissions. Thankfully, I was eventually able to use Facebook's JavaScript SDK for authentication.3 In a marathon session about a week ago, I was able to write a new web-based application4, install RabbitMQ and Celery (for asynchronously downloading photographs), and test the entire workflow, all within a few hours.
The entire setup has been running reasonably well for the past week. There are still some tasks to do (allow downloaded photographs to be manually deleted from the server, create more documentation to better explain to users how everything works, more error handling, etc.), but the scary parts are finished.
Previously, applications were given access to almost all user information, which meant that an application masquerading as an online poll or virtual game could clandestinely gather personal information about you and your friends. Such practices are prohibited under the terms of service for the application developers' program, but would previously only be detected after the fact. The permissions change require applications to explicitly request permissions for most sensitive data - making it easier to notice that your farming game is asking to get information on your political preferences and your friends' relationship status. ↩
If I had been keeping up-to-date with the latest Facebook development news instead of trying to move all of my personal belongings 400 miles, I might have noticed. ↩
Any programmer in the same position will want to see the section entitled "Single Sign-on with the JavaScript SDK" in Facebook's documentation on authentication. This should work regardless of what language your web application is written in. ↩
Desktop Facebook applications are second-class citizens, mainly because the vast majority of applications are web-based. Since they live on client computers (as opposed to a centralized web server), they are harder to upgrade and troubleshoot. Because of this, I had considered rewriting the application to run on the Internet for a while. I hope that the new application will allow me to respond more quickly to changes in the future, so that a similar situation will not occur again. ↩