You may have caught this on the Twitter Development Talk Google Group, but last week we made a change to our crossdomain.xml file.
Previously, we allowed Flash applications hosted anywhere on the web to make requests to the Twitter API. Unfortunately, a proof-of-concept security flaw was demonstrated that would allow malicious Flash applications to make requests on behalf of users logged-in to Twitter. So, for the time being, our crossdomain.xml only allows applications hosted at Twitter domains or other domains approved by our team to talk to our API.
If your Flash app needs to talk to the Twitter API, the primary way around this is to host a proxy to the Twitter API on your domain. Beyond that, we're open to suggestions, and we've been collecting them on the aforementioned Google Group. We don't want to make Flash developers second-class citizens, but we also need to act with our users' security in mind.
Monday, March 17, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
There's two approaches to this that I've seen:
* Give the API its own domain that isn't susceptible to XSRF (e.g. no cookies)
* Make a special API bridge for Flash that gets loadMovie'd in (a SWF file on twitter that talks via LocalConnection or the like to the calling movie, and then forwards requests to the internal URLs)
We normally do the latter because it lets us upgrade code on the fly, but the former is a hell of a lot easier.
An api subdomain would be the best option.. Flickr does that as well.
(http://api.flickr.com/crossdomain.xml)
Thanks!
Post a Comment