[twitter-dev] List creation with oAuth credentials
The current endpoint for creating a new list is: http://api.twitter.com/1/user/lists.format But the user part is meant to be the user's screen name. If your application is oAuth, you don't necessarily know or care about the user's screen name. You can easily get it with a verify_credentials call. However, this is the first time that an API endpoint has required two calls to be useful. Why would the user part of the URL be necessary at all if authentication is required?
[twitter-dev] Re: Show a specific list you can use the new resource
On Nov 7, 12:31 pm, Matthew Terenzio mteren...@gmail.com wrote: Can someone explain this? GET '/:users/lists/:list_slug.:format' Show a specific list you can use the new resource. is scripting examples of how to use the Lists API will help, take a look at: http://www.ist.rit.edu/~jxs/tools/scripting/twitterLists.html jeffs
[twitter-dev] Time zone support
Hi, Any plans to implement timezone support? It's weird to say Good morning at 5h45 from Switzerland and see it appear as 19h45 in the public timeline / on some profiles... It doesn't make sense to me... The time should be written with the mention of the time zone, e.g.: 05:45 CEST. An other suggestion could be to display the time in both formats: e.g.: 05:45 CEST / 10:15 IST | poster's timezone / reader's timezone. Choice should be given to the user whether to display the message timestamps with timezone support or no. Regards, Emrah
[twitter-dev] Re: crossdomain.xml files back on twitter.com and search.twitter.com
Any update on when a similar policy will be put into place on api.twitter.com? This was promised a year and a half ago. A lot of folks are asking for it, as can be seen in this thread: http://groups.google.com/group/twitter-development-talk/browse_frm/thread/e35a708400b529b3 On Nov 6, 8:40 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. we've put the following crossdomain.xml onto search.twitter.com ?xml version=1.0? !DOCTYPE cross-domain-policy SYSTEM http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd cross-domain-policy allow-access-from domain=* / /cross-domain-policy hopefully this fixes most people's apps! we're aiming to stay with this policy on search. Any update on why the change in the search crossdomain? is it permanent? you should at least give developers time to prepare hi all. the crossdomain.xml files are back on twitter.com and search.twitter.com -- sorry for the accidental removal. feel free to reach out if you have any issues. thanks! -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: List creation with oAuth credentials
Twitter API team seems to want to make the API more RESTful. So that is my guess why that end point is /:user/lists.xml POST versus something like /lists/create.xml Josh On Sun, Nov 8, 2009 at 2:25 AM, Dimebrain daniel.cre...@gmail.com wrote: The current endpoint for creating a new list is: http://api.twitter.com/1/user/lists.format But the user part is meant to be the user's screen name. If your application is oAuth, you don't necessarily know or care about the user's screen name. You can easily get it with a verify_credentials call. However, this is the first time that an API endpoint has required two calls to be useful. Why would the user part of the URL be necessary at all if authentication is required?
[twitter-dev] Re: crossdomain
Please keep us updated w/ discussion on relaxing the crossdomain policy on api.twitter.com. Currently it is impossible to build full featured in-browser Flash clients for Twitter without using a proxy, which is part of the reason so many of them are desktop AIR apps. Twitter is doing itself a disservice by blocking API access to a large number of developers. Please see this thread of Flash developers asking for this: http://groups.google.com/group/twitter-development-talk/browse_frm/thread/e35a708400b529b3 On Nov 7, 11:38 am, Raffi Krikorian ra...@twitter.com wrote: hi tim. the crossdomain.xml file is now open an unrestricted to search. in the future, as part of the migration to api.twitter.com for API endpoints, we may consider relaxing a crossdomain.xml policy on that. John I'm with others here that this represents a significant change to the operation of the API and has affected numerous applications and samples, etc. Frankly I wish Twitter would really understand x-domain policy files better. If there is a concern around security, then address it and don't allow *user* changes on the API domain root. I fully understand the reason for x-domain policies as we need them for Silverlight as well -- and appreciate how they help mitigate the attack surface. But especially for Search, which is an unauthenticated API it doesn't make sense. Having twitter segment their API (or provide a different endpoint for RIA clients that has the security risk mitigation in place) seems to make sence. That's exactly what others (Yahoo, Microsoft, etc.) do -- instead of hanging their API off of the end- user application it is segmented (i.e., yahooapis.com or api.twitter.com) so as to help the security threat surface. Twitter doesn't block domains from using the services otherwise and having a x-domain policy in place that is DIFFERENT than what is allowed in the API in general is very confusing to the developer audience. Please change the Search API back ASAP as that in the short-term has the greatest negative effect on a lot of applications that relied on it and are now affected TWICE in one week without notification. Users of the transactional API always knew from the very beginning about the x-domain policy file (even though it, too, went through a change early on), but the Search API hasn't been like this for a long time. Consider your developer audience in the short-term while you consider a longer-term solution. And until then, provide us with a phase-out plan instead of a complete shut-off which negatively affects us and our customers. I understand Twitter is a free service and such has the typical SLA that comes along with free. But it has been an invaluable service to your customers and ours -- I also agree with others that making these announcements BEFORE the changes on status.twitter.com and these lists as well as the official API announce is essential. There has only been answers on these issues based on questions -- nothing pro-active from your team about the changes or what is going on. -th On Nov 6, 7:35 am, Marauderz maraud...@gmail.com wrote: John, Even before last week, our Flash apps could always access search.twitter.com. means that the crossdomain.xml had always allowed universal access before. So it is NOT the same state that it was last week. The change in the crossdomain.xml will mean that all the Flash, Silverlight and any other platform that respects a crossdomain.xml file are now essentially broken by this change. I understand the concerns for security, but maybe you could then think of setting up another domain for RIA app search use instead then? In any case, a lot of twitter apps have just been silenced because of this crossdomain.xml change. On Nov 6, 8:08 am, John Adams j...@twitter.com wrote: On Nov 5, 2009, at 3:32 PM, codewarrior415 wrote: OK, the crossdomain policy now only allows your flex application to access the API. You are not allowing flex appication access your API? How come the change again today. This morning it was working fine. twitter.com's crossdomain.xml is exactly the same as it was last week, it was restored from the original configuration. The search.twitter.com crossdomain.xml policy was incorrectly set to permit from all sites for all actions. We've configured that to be identical to the twitter.com crossdomain.xml to prevent CSRF, session fixation, and attacks on user accounts, which is a major security issue which Facebook and Myspace fell to earlier this week. Could you describe what you are trying to do and we'll research? -john -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: List creation with oAuth credentials
I thought this too when I first saw the new list api. Is the Twitter team moving away from id/screenname based query parameters and simply using screen names? I suppose the point being that Daniel was making is that screen name is superflous when using authentication especially since all the POST, PUT and DELETE commands will require authentication to work. It would be good to at least know which url structure Twitter intend to support because as it stands now their is a disjoint between this new API and the old ones. P Sent from my iPhone On 8 Nov 2009, at 16:49, Josh Roesslein jroessl...@gmail.com wrote: Twitter API team seems to want to make the API more RESTful. So that is my guess why that end point is /:user/lists.xml POST versus something like /lists/ create.xml Josh On Sun, Nov 8, 2009 at 2:25 AM, Dimebrain daniel.cre...@gmail.com wrote: The current endpoint for creating a new list is: http://api.twitter.com/1/user/lists.format But the user part is meant to be the user's screen name. If your application is oAuth, you don't necessarily know or care about the user's screen name. You can easily get it with a verify_credentials call. However, this is the first time that an API endpoint has required two calls to be useful. Why would the user part of the URL be necessary at all if authentication is required?
[twitter-dev] Re: List creation with oAuth credentials
Yeah I agree and wished twitter would have just kept the design more consistent to what is already there. If they want to change the design, do it all at once and save it for another version (maybe 2 or something). On Sun, Nov 8, 2009 at 10:59 AM, Paul Kinlan paul.kin...@gmail.com wrote: I thought this too when I first saw the new list api. Is the Twitter team moving away from id/screenname based query parameters and simply using screen names? I suppose the point being that Daniel was making is that screen name is superflous when using authentication especially since all the POST, PUT and DELETE commands will require authentication to work. It would be good to at least know which url structure Twitter intend to support because as it stands now their is a disjoint between this new API and the old ones. P Sent from my iPhone On 8 Nov 2009, at 16:49, Josh Roesslein jroessl...@gmail.com wrote: Twitter API team seems to want to make the API more RESTful. So that is my guess why that end point is /:user/lists.xml POST versus something like /lists/ create.xml Josh On Sun, Nov 8, 2009 at 2:25 AM, Dimebrain daniel.cre...@gmail.com wrote: The current endpoint for creating a new list is: http://api.twitter.com/1/user/lists.format But the user part is meant to be the user's screen name. If your application is oAuth, you don't necessarily know or care about the user's screen name. You can easily get it with a verify_credentials call. However, this is the first time that an API endpoint has required two calls to be useful. Why would the user part of the URL be necessary at all if authentication is required?
[twitter-dev] Re: Time zone support
hi emrah. this sounds interesting -- how do you handle people who are traveling and may not be in their home timezone when they say good morning? Hi, Any plans to implement timezone support? It's weird to say Good morning at 5h45 from Switzerland and see it appear as 19h45 in the public timeline / on some profiles... It doesn't make sense to me... The time should be written with the mention of the time zone, e.g.: 05:45 CEST. An other suggestion could be to display the time in both formats: e.g.: 05:45 CEST / 10:15 IST | poster's timezone / reader's timezone. Choice should be given to the user whether to display the message timestamps with timezone support or no. Regards, Emrah -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: crossdomain.xml files back on twitter.com and search.twitter.com
hi! we're definitely discussing it heavily internally now that api.twitter.com has been launched and we are attempting to migrate all developers to use that endpoint instead of the twitter.com endpoints. we'll definitely keep people updated as we think these through. of course, we always welcome discussion -- so please feel free to chime in with ideas, concerns, etc. Any update on when a similar policy will be put into place on api.twitter.com? This was promised a year and a half ago. A lot of folks are asking for it, as can be seen in this thread: http://groups.google.com/group/twitter-development-talk/browse_frm/thread/e35a708400b529b3 hi all. we've put the following crossdomain.xml onto search.twitter.com ?xml version=1.0? !DOCTYPE cross-domain-policy SYSTEM http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd cross-domain-policy allow-access-from domain=* / /cross-domain-policy hopefully this fixes most people's apps! we're aiming to stay with this policy on search. Any update on why the change in the search crossdomain? is it permanent? you should at least give developers time to prepare hi all. the crossdomain.xml files are back on twitter.com and search.twitter.com -- sorry for the accidental removal. feel free to reach out if you have any issues. thanks! -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] 404s from OAuth?
I'm seeing 404s from OAuth suddenly, when trying to hit... http://api.twitter.com/1/oauth/request_token?[query string removed[ ...but getting normal responses from http://api.twitter.com/oauth/request_token I thought the /1/ was standard at this point. Was I mistaken, or is this just a blip?
[twitter-dev] Re: 404s from OAuth?
oauth, as it is not being versioned is available at api.twitter.com (and not, /1) -- we may consider aliasing it at some point if necessary. I'm seeing 404s from OAuth suddenly, when trying to hit... http://api.twitter.com/1/oauth/request_token?[query string removed[ ...but getting normal responses from http://api.twitter.com/oauth/request_token I thought the /1/ was standard at this point. Was I mistaken, or is this just a blip? -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: crossdomain.xml files back on twitter.com and search.twitter.com
Very glad to hear that! I'm going to reach out to my fellow Flashers again to see who can give solid advice on opening up the crossdomain policy while maintaining security. On Nov 8, 6:55 pm, Raffi Krikorian ra...@twitter.com wrote: hi! we're definitely discussing it heavily internally now that api.twitter.com has been launched and we are attempting to migrate all developers to use that endpoint instead of the twitter.com endpoints. we'll definitely keep people updated as we think these through. of course, we always welcome discussion -- so please feel free to chime in with ideas, concerns, etc. Any update on when a similar policy will be put into place on api.twitter.com? This was promised a year and a half ago. A lot of folks are asking for it, as can be seen in this thread: http://groups.google.com/group/twitter-development-talk/browse_frm/th... hi all. we've put the following crossdomain.xml onto search.twitter.com ?xml version=1.0? !DOCTYPE cross-domain-policy SYSTEM http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd cross-domain-policy allow-access-from domain=* / /cross-domain-policy hopefully this fixes most people's apps! we're aiming to stay with this policy on search. Any update on why the change in the search crossdomain? is it permanent? you should at least give developers time to prepare hi all. the crossdomain.xml files are back on twitter.com and search.twitter.com -- sorry for the accidental removal. feel free to reach out if you have any issues. thanks! -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: crossdomain.xml files back on twitter.com and search.twitter.com
that sounds great -- please feel free to continue this discussion on this list, or just reach out to me personally. Very glad to hear that! I'm going to reach out to my fellow Flashers again to see who can give solid advice on opening up the crossdomain policy while maintaining security. hi! we're definitely discussing it heavily internally now that api.twitter.com has been launched and we are attempting to migrate all developers to use that endpoint instead of the twitter.com endpoints. we'll definitely keep people updated as we think these through. of course, we always welcome discussion -- so please feel free to chime in with ideas, concerns, etc. Any update on when a similar policy will be put into place on api.twitter.com? This was promised a year and a half ago. A lot of folks are asking for it, as can be seen in this thread: http://groups.google.com/group/twitter-development-talk/browse_frm/th ... hi all. we've put the following crossdomain.xml onto search.twitter.com ?xml version=1.0? !DOCTYPE cross-domain-policy SYSTEM http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd cross-domain-policy allow-access-from domain=* / /cross-domain-policy hopefully this fixes most people's apps! we're aiming to stay with this policy on search. Any update on why the change in the search crossdomain? is it permanent? you should at least give developers time to prepare hi all. the crossdomain.xml files are back on twitter.com and search.twitter.com -- sorry for the accidental removal. feel free to reach out if you have any issues. thanks! -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: Time zone support
Raffi Krikorian wrote: hi emrah. this sounds interesting -- how do you handle people who are traveling and may not be in their home timezone when they say good morning? :) Timezone code could be set per Tweet as a parameter. E.g.: on mobile phones, the time is usually updated from the network operator and on most computers from an NNTP. Obviously the user experience should not be changed and the timezone must be discovered and set automatically. Regards, Emrah
[twitter-dev] Re: Making crossdomain.xml less restrictive on api.twitter.com?
Chad Etzel c...@twitter.com wrote: After discussing this internally, we have decided that we will make thecrossdomain.xml policy more open on the api.twitter.com domain. We don't know exactly what that entails yet or when it will go into effect, but this is something that we want to open up. Another +1 on this. I'm about to deploy a Flash app giving users the option to send tweets and which will have to use a proxy for now. I really don't like doing this as there's always the suspicion that I could use it to harvest users' names and passwords - though of course I'm not doing! A permissive crossdomain.xml would be a huge boost. Richard
[twitter-dev] Searching for users
Is there a way to use the Twitter API to search for a user using partial strings or booleans? Let's say, searching for hello and coming back with @helloluis, @hellotoni, @helloworld, etc.? (Ideally, hashes of these users' profiles?) If not, is there a way to cobble this functionality together somehow? I've been looking around and can't find an obvious way to do this. :luis
[twitter-dev] Re: Geocode Problem
Hi, sorry for the trouble caused, think have managed to solve it. turns out to be my mistake, i did not remove the negative sign from the example, i just replace the number which is why i could not get anything. Thanks a lot for your help! On Thu, Nov 5, 2009 at 5:14 PM, Rich rhyl...@gmail.com wrote: Those coodinates are in the middle of the ocean according to Google Maps so that might very well be why it doesn't work. On Nov 5, 3:03 am, pipigu85 pipig...@gmail.com wrote: Hi, i was looking through the twitter search api to find something that could limit my search to Singapore and thought geocode could help. I tried the link in the example and it was able to work but when i replace it with singapore's coordinates taken from google maps, a HTTP 403 Forbidden error appears. Could someone help? thks This is the link i was trying out with to narrow search down to Singapore: http://search.twitter.com/search.atom?geocode=1.397185%2C-103.807068%...
[twitter-dev] Unable to get recent results using geocode
Hi, tried using the geocode http://search.twitter.com/search.atom?q=NYPgeocode=1.356771%2C103.824062%2C25kmpage=1rpp=100, location is Nanyang Polytechnic in Singapore and its surrounding 25km. The latest result it returns is from the 4th of Nov when today is already 9th Nov and when i remove the geocode, it is able to display tweets from 9th. From the details of some tweets, I am sure that it is sent from NYP itself. Not sure where it goes wrong. Can someone help? Thanks
