Facebook will POST data to apps(developers.facebook.com)
developers.facebook.com
Facebook will POST data to apps
http://developers.facebook.com/docs/canvas/post
7 comments
Not to mention application developers -- big or small -- are going to have a much simpler time changing (or not at all) their applications to receive on POST kwargs (or REQUEST). You have reason to be dogmatic about HTTP, but this hardly a cause to lash out against engineers as stupid or over-paid.
How does one submit custom headers along with a form?
Seems like a POST is a perfectly valid way to handle it.
Seems like a POST is a perfectly valid way to handle it.
I'm not excited about having to go through all my apps to update them for this. It's going to be hours of work, followed by weeks of users reporting subtle bugs that cropped up as a result.
This kind of frequent, sweeping change is the reason why people despise the Facebook platform.
This kind of frequent, sweeping change is the reason why people despise the Facebook platform.
There's a setting you can flip to turn this on now for testing. It doesn't affect a lot, just which particular request variables array you need to pull from. In many languages, you might not even need to make a change on your end.
Relax, after you finish it will only be a couple of weeks until you are finally able to get rid of it all. Of course no one will tell you that time...
Looks like this is a response to the privacy breach reported last month by the Wall Street Journal: http://online.wsj.com/article/SB1000142405270230477280457555... (HN thread http://news.ycombinator.com/item?id=1801898)
From that article:
It's not clear if developers of many of the apps transmitting Facebook ID numbers even knew that their apps were doing so. The apps were using a common Web standard, known as a "referer," which passes on the address of the last page viewed when a user clicks on a link. On Facebook and other social-networking sites, referers can expose a user's identity.
From this article:
Sadly, all those parameters [identifying the Facebook user etc] go in the URL [by which your Facebook app is invoked] and if you app includes any other external resources (iframes, imgs, scripts, etc.) that sensitive data gets passed along to them in the HTTP Referer header.
From that article:
It's not clear if developers of many of the apps transmitting Facebook ID numbers even knew that their apps were doing so. The apps were using a common Web standard, known as a "referer," which passes on the address of the last page viewed when a user clicks on a link. On Facebook and other social-networking sites, referers can expose a user's identity.
From this article:
Sadly, all those parameters [identifying the Facebook user etc] go in the URL [by which your Facebook app is invoked] and if you app includes any other external resources (iframes, imgs, scripts, etc.) that sensitive data gets passed along to them in the HTTP Referer header.
Per RFC 2616, the POST method should be used for any context in which a request is non-idempotent: that is, it causes a change in server state each time it is performed, such as submitting a comment to a blog post or voting in an online poll.
The solution to the security problem is to not pass the authentication data in the query string which is intended for specifying parameters that vary the result of the performed query. Instead the authentication data should be passed as custom HTTP headers. E.g. "X-Fb-Sig-User: 218471".
I am very amazed that this is not common knowledge. This is a 20 years old protocol that might possibly be the most widely used and implemented high level communication protocol in human history. Get your shit together people. Seriously!
edit: I guess I was a bit quick to judge. Didn't realize that the request originates from an iframe in a browser where you can't easily set custom HTTP headers. Maybe it is possible to do with some XMLHttpRequest magic, but I can't think of a solution that would work of the top of my head.