[twitter-dev] 401 unauthorized
My website uses twitter for authentication, For the past 24 hours the OAuth sign in is continuously returning 401 , i am not able to figure out what to do? Has some one faced similar problems? My site has been down for 24 hours now because of this. please help me out here.
Re: [twitter-dev] Re: Retweets and the Public Timeline
On Tue, Dec 22, 2009 at 10:42 AM, Raffi Krikorian ra...@twitter.com wrote: go code something interesting, and we will be here to support you. (of course, if we missed something, as we are arguing about in the RT case, we will work with you all to get it to be what the community needs). So does this mean RTs will be restored as is being requested? I don't think anyone is questioning that you need to be creative with the Twitter API. Jesse
Re: [twitter-dev] Oauth using api.twitter.com vs twitter.com
Hello, Just wanted to make a quick update here. I have patched Tweepy to use 'twitter.com' as the host for the OAuth setup. This should resolve the issue for now until Twitter resolves this issue [1]. Josh Tweepy Author [1] http://code.google.com/p/twitter-api/issues/detail?id=1207
[twitter-dev] Re: Docs wrong for retweets method? Count seems to be ignored if 20
I've reported this through several means (tweets to TwitterApi, post on this forum, etc.). Seems to be a bug that I too would like to see fixed! On Dec 30, 8:51 pm, Tim Haines tmhai...@gmail.com wrote: Hey guys, I'm trying: curl -u timhaines:123#notreallyhttp://twitter.com/statuses/retweets/5635825799.json?count=100 and only the first 20 RTs are being returned. Same with the xml method. The docs (http://apiwiki.twitter.com/Twitter-REST-API-Method:-statuses-retweets) say you should be able to fetch up to the first 100. Am I doing it wrong? Or Doc/API bug? Tim.
[twitter-dev] Re: issues with retweets and API
The retweeted status is only available if the tweet is a retweet. Thats why I was suggesting there be a variable like retweeted_by_me in the original tweet to let you know you've retweeted it so you can Undo. If this were to be implemented there needs to be a new method to Undo the retweet which takes in the original tweet id. Since you don't have the id of the retweet you cannot call statuses/destroy. If you call it using the original id it results in an error since you don't own the tweet. Right now retweets are a one-way action with the API. If you need to unfavorite a retweet you must go to your favorites and unfavorite the tweet and if you want to Undo a retweet you need to use statuses/ retweeted_by_me and destroy the retweet. It seems like twitter.com handles favoriting and retweeting well so there seems to be some discrepancy between what twitter.com uses and the API.
[twitter-dev] Re: Retweets and the Public Timeline
i can't speak as to whether we're going to put them into the user_timeline or not -- although, i would suspect no, as it has the potential for breaking legacy applications, and it is something we could revisit in a future version of the API (e.g. a hypothetical api.twitter.com/2). again, for clarity, i'm don't know for sure. if developers would like the equivalent of a user_timeline that has retweets in it, then they could easily fetch the following two timelines: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-user_timeline http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_by_me and merge them together to form a virtual timeline. On Dec 31, 2:24 am, Jesse Stay jesses...@gmail.com wrote: On Tue, Dec 22, 2009 at 10:42 AM, Raffi Krikorian ra...@twitter.com wrote: go code something interesting, and we will be here to support you. (of course, if we missed something, as we are arguing about in the RT case, we will work with you all to get it to be what the community needs). So does this mean RTs will be restored as is being requested? I don't think anyone is questioning that you need to be creative with the Twitter API. Jesse
[twitter-dev] Re: What You Put In Not The Same As What You Get Back Out
I've noticed that you keep the filename. That was kind of annoying for other reasons: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/1f63694495c02ff/a713748c19c35895 If I just check the filename, I can't be sure that the file wasn't changed by the user. It would be nice if the account/ update_profile_background_image function could guarantee that the image URL returned was the actual image I uploaded. (with whatever filtering you want to apply) -- Kyle Mulka Founder, Congo Labs http://twilk.com On Dec 30, 8:03 pm, John Adams j...@twitter.com wrote: On Dec 30, 2009, at 4:21 PM, Kyle Mulka wrote: My application uploads a background image on a user's behalf. I want to be able to figure out if they are still using the background image at some future point in time. The filename might work as a test for this, instead of the computationally expensive MD5 on an image hack. We still retain the original file (basename) on images. -j --- John Adams (@netik) Twitter Operations j...@twitter.comhttp://twitter.com/netik
