[twitter-dev] Re: Cross-domain policy file
MySpace - allows all domains http://api.myspace.com/crossdomain.xml On Oct 19, 10:53 am, zeh fernando wrote: > Thanks for the support Orian. I really want to understand why Twitter > is blocking that kind of cross-domain requests, as I believe it just > makes things more difficult, without really blocking what one would > consider a "security issue". > > On Oct 19, 3:10 am, "Orian Marx (@orian)" wrote: > > > 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 wrote: > > > > Does Twitter have any plans on when/whether they'll change its current > > > cross-domain policy file? > > > >http://api.twitter.com/crossdomain.xmldoesnotallow 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-allowsconnections from > > > all domainshttp://api.flickr.com/crossdomain.xml-allowsconnections from > > > all > > > domainshttp://api.plixi.com/crossdomain.xml-allowsconnections from all > > > domainshttp://api.bit.ly/crossdomain.xml-allowsconnections from all > > > domainshttp://stream.twitvid.com/crossdomain.xml-allowsconnections 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
[twitter-dev] Re: Cross-domain policy file
Thanks for the support Orian. I really want to understand why Twitter is blocking that kind of cross-domain requests, as I believe it just makes things more difficult, without really blocking what one would consider a "security issue". On Oct 19, 3:10 am, "Orian Marx (@orian)" wrote: > 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 wrote: > > > Does Twitter have any plans on when/whether they'll change its current > > cross-domain policy file? > > >http://api.twitter.com/crossdomain.xmldoesnot 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
[twitter-dev] Re: Cross-domain policy file
Yahoo! maps APIs - allows all domains http://local.yahooapis.com/crossdomain.xml Yahoo! search APIs - allows all domains http://search.yahooapis.com/crossdomain.xml On Oct 18, 3:34 pm, zeh fernando 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
[twitter-dev] Re: Cross-domain policy file
Just to add some other examples of popular API domains: Youtube API cross-domain policies - allow connections from all (real) domains http://gdata.youtube.com/crossdomain.xml Google search APIs - allow conection from all domains http://ajax.googleapis.com/crossdomain.xml Ebay APIs - allow connection from all domains http://svcs.ebay.com/crossdomain.xml Delicious APIs - allow connections from all domains https://api.del.icio.us/crossdomain.xml Last.fm APIs - allow connections from all domains http://ws.audioscrobbler.com/crossdomain.xml Bing Maps APIs - allow connections from all domains http://ecn.dev.virtualearth.net/crossdomain.xml See a trend here? Zeh On Oct 18, 3:34 pm, zeh fernando 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
[twitter-dev] Cross-domain policy file
Does Twitter have any plans on when/whether they'll change its current cross-domain policy file? http://api.twitter.com/crossdomain.xml does 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/thread/8d09970f449abc70 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.xml http://groups.google.com/group/twitter-development-talk/browse_thread/thread/fa7c3f42f85b8d3 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 domains http://api.flickr.com/crossdomain.xml - allows connections from all domains http://api.plixi.com/crossdomain.xml - allows connections from all domains http://api.bit.ly/crossdomain.xml - allows connections from all domains http://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