Zeh, thanks for taking the time to bring this issue to light again and to present so many examples of other significant APIs that do not have restrictive crossdomain policies. As you note, this issue has been brought to Twitter's attention several times over the last few years but to no avail.
For my work I continue to have to rely on a PHP proxy for all calls between my Flash client and Twitter. This is certainly not ideal. Team Twitter, it's time for you to address this issue. One of the most popular clients for Twitter out there, TweetDeck, is built with Flash technology and yet runs as an AIR app I'm guessing in part because that has a different security model and does not have to deal with this. You should recognize that there is a large pool of developer talent that has, over the years, attempted to build wonderful things on your platform but have thrown up their hands and left due to frustration with this crossdomain policy. Please stop treating us as second class developers. Thanks, Orian On Oct 18, 3:34 pm, zeh fernando <z...@zehfernando.com> wrote: > Does Twitter have any plans on when/whether they'll change its current > cross-domain policy file? > > http://api.twitter.com/crossdomain.xmldoes not allow requests from > Flash-based websites and web apps because it restricts response to > twitter.com subdomains. > > http://search.twitter.com/crossdomain.xml, however, does allow Flash > requests from any domain. > > This policy pretty much renders all Flash calls to the API useless > (unless they're search calls). > > One could use proxy scripts, but given the limitations imposed by the > Twitter API (150 calls per IP per hour), it means public websites are > out of luck if they're getting any kind of public data without > authenticating like, say, getting a (public) user timeline. > > This has been discussed at length in previous threads. > > Change in > crossdomain.xml??http://groups.google.com/group/twitter-development-talk/browse_thread... > > Most curiously, the above thread mentions on March 2008 that Twitter > would be moving API calls to api.twitter.com and allowing a more > permissive crossdomain policy file there in a few months. This hasn't > happened, though, since people have continued to be dumbfounded by the > inability to load Twitter data from Flash-based web apps. > > Twitter Stream > crossdomain.xmlhttp://groups.google.com/group/twitter-development-talk/browse_thread... > > I think this decision is specially questionable as the cross-domain > restrictions in place do nothing else other than put a tax on what > people can do from Flash-based web apps, but also allow any other > usage from any other technology, be it a security issue or not. In > fact, even using PHP proxies one could make the API calls from Flash > (albeit in a restricted manner) so I can't see a real reason for > singling out/blocking this platform. > > Normally, public APIs add no such artificial/ineffective restrictions, > and simply allow any kind of connection (doing their own top of their > own built-in restrictions and rate limiting)... > > http://graph.facebook.com/crossdomain.xml- allows connections from > all domainshttp://api.flickr.com/crossdomain.xml- allows connections from all > domainshttp://api.plixi.com/crossdomain.xml- allows connections from all > domainshttp://api.bit.ly/crossdomain.xml- allows connections from all > domainshttp://stream.twitvid.com/crossdomain.xml- allows connections from > all domains > ...etc etc > > So, is there any clear reason why the restriction is still in place? > Or any idea on when this policy will be reviewed? > > Thanks, > Zeh -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
