[twitter-dev] Re: Important Notice on Incorrect API Endpoints for Search, REST, & OAuth (+ some general tips!)
Are you all aware of this bug?
http://code.google.com/p/twitter-api/issues/detail?id=1154
We can't reliably use since_id for searches until this is fixed.
On May 27, 6:12 pm, Taylor Singletary
wrote:
> Hi Developers,
>
> A few quick points before I go into more detail:
>
> * For the Search API, you should *only* be
> usinghttp://search.twitter.comtoexecute search requests.
> *Not*http://api.twitter.com/1/searchor any other variation.
>
> * *Next week*, we plan to remove the erroneous, unsupported endpoint
> athttp://api.twitter.com/1/search
>
> * All REST requests to the API should use the fully qualified hostname and
> API version in URLs:http://api.twitter.com/1/*-- no other version is valid
> at this time.
>
> * All OAuth negotiation steps should be over SSL and also
> athttp://api.twitter.com-- but without a version.
>
> * Don't execute the same search query more often than every 20s and always
> use since_id on subsequent requests
>
> * Consider the streaming API if you're relying on search heavily to power
> your application
>
> *The Long-winded Approach*
> *
> *
> The only endpoint you should be using for search operations in the Twitter
> API today ishttp://search.twitter.com-- it doesn't require user
> authentication or OAuth -- simply identify yourself with a user-agent that
> is unique to your application.
>
> For those usinghttp://twitter.com/search,http://api.twitter.com/search,
> orhttp://api.twitter.com/1/search-- you've been doing it wrong :)
>
> Though we should have rejected traffic to that end point long ago to avoid
> confusion, it was never intended as a valid resource for search queries.
>
> Next week, we'll be properly closing off this end point to avoid further
> confusion. If you have code today that uses thehttp://api.twitter.comor
> http:/twitter.com domains to execute search requests, be sure and update
> your code for the proper end point.
>
> You can find the Search API documentation athttp://bit.ly/twitter-search-api
>
> Many users of the Search API are better served by using the Streaming API.
> If you use the search API to track the tweets of specific users, hashtags,
> or simple keyword queries, it is highly recommended that you use the
> Streaming API instead.
>
> You shouldn't issue the same request to the search API more frequently than
> once every 20 seconds -- if you issue the same query more frequently than
> that, you're in danger of getting blacklisted. In addition, if you find
> yourself repeating the same query frequently, be sure and make use of the
> since_id parameter on subsequent requests -- without it, you put undue
> stress on the search infrastructure and will also be in danger of
> blacklisting.
>
> While we're on the topic of using the proper endpoints, a general reminder
> about endpoints with the Twitter API:
>
> All REST resource requests, with the exception of Search, should be pointed
> athttp://api.twitter.com/1/*-- always use the api subdomain and specify
> the version number ("1"). No other version number will be accepted for the
> API at this time and your requests will fail if you provide a different
> string or integer.
>
> All OAuth negotiation steps should be over SSL
> athttps://api.twitter.com/oauth/*("https://api.twitter.com/oauth/request_token";,
> "https://api.twitter.com/oauth/authorize";,
> "https://api.twitter.com/oauth/access_token";,
> "https://api.twitter.com/oauth/authenticate";)
>
> Let us know if you have any concerns about the removal of the
> unofficial/unsupported search end point. We don't want to break people, but
> we also don't want you using unofficial API calls with substandard and
> unpredictable responses.
>
> Thanks!
>
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod
[twitter-dev] Re: 401 - Unauthorized error when diacritics in status
I'm not sure if this is the same issue you are encountering, but I had a similar issue in my C# twitter app. The post I made is here: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/ef11efdd0a9cf194/6950ce9721a48609#6950ce9721a48609 On Feb 23, 2:13 pm, Ryan Alford wrote: > I think it is the way that .Net handles encoding of the diacritics. I don't > think it's a Twitter api issue. I was hoping that another .Net developer > had run into this issue and had fixed it. > > Ryan > > On Tue, Feb 23, 2010 at 2:07 PM, Raffi Krikorian wrote: > > this would be news to me - if you have a way to replicate this, and you are > > confident its not your oauth libraries, then please let me know. > > > On Tue, Feb 23, 2010 at 11:04 AM, Ryan Alford > > wrote: > > >> I believe it has been fixed in some libraries in other programming > >> languages, but I can't figure out how to do it in .Net. > > >> Ryan > > >> On Tue, Feb 23, 2010 at 12:38 PM, Aral Balkan wrote: > > >>> Ooh, if this is the case then it will definitely stop me from using oAuth > >>> for Feathers (http://feathersapp.com) since diacritics are an essential > >>> part of Unicode art. > > >>> Very interested in hearing what you find out. > > >>> All the best, > >>> Aral > > >>> On Tue, Feb 23, 2010 at 1:44 PM, eclipsed4utoo > >>> wrote: > > I am getting an error message when posting accent marks and other > diacritics in a status update. > > I saw that there was an issue [1] posted in April of last year about > this problem. It seems to be with the signature generation for OAuth > with the encoding of accent marks. > > I am using .Net(C#), and I can't figure out how to fix this. Do I use > a different encoding? Anybody have any ideas on how to fix this > in .Net? > > [1] -http://code.google.com/p/twitter-api/issues/detail?id=433 > > Ryan > > > -- > > Raffi Krikorian > > Twitter Platform Team > >http://twitter.com/raffi
[twitter-dev] Re: 404 Errors on friends and followers using cursors
As far as I can tell, there has been no progress on this. There is a
bug open for the issue, if you would like to follow it:
http://code.google.com/p/twitter-api/issues/detail?id=1264
On Jan 9, 8:30 am, bear wrote:
> I am now seeing this on some of my own accounts - has any movement or
> fix been applied?
>
> here is the url i'm trying:
>
> curlhttp://twitter.com/statuses/friends/codebear.json <-- returns
> []
> curlhttp://twitter.com/statuses/friends/manta.json <-- returns
> {"request":"/statuses/friends/manta.json","error":"Not found"}
>
> On Dec 28 2009, 2:42 pm, Mageuzi wrote:
>
> > Sorry to keep bringing this up, but this is still causing problems for
> > me. Is there any follow-up as to what the issue is? Thanks in
> > advance.
>
> > On Dec 22, 10:06 pm, Mageuzi wrote:
>
> > > Is there an update to the status of this issue? A user of my program
> > > reported a problem that ended up being this. While trying to iterate
> > > through:http://api.twitter.com/1/statuses/friends/oevl.xml
> > > Cursor 1274505087418535016 returned fine and contained a next_cursor
> > > value of 1267920196862230269. That value returned a 404.
>
> > > On Dec 8, 1:32 pm, Ammo Collector wrote:
>
> > > > If you get the following URLs and continue to using the next_cursor,
> > > > you receive incorrect 404s:
>
> > > >http://twitter.com/statuses/friends/debra_bee.xml?cursor=130554434315...
>
> > > > Any ideas?
[twitter-dev] Re: 404 Errors on friends and followers using cursors
Sorry to keep bringing this up, but this is still causing problems for me. Is there any follow-up as to what the issue is? Thanks in advance. On Dec 22, 10:06 pm, Mageuzi wrote: > Is there an update to the status of this issue? A user of my program > reported a problem that ended up being this. While trying to iterate > through:http://api.twitter.com/1/statuses/friends/oevl.xml > Cursor 1274505087418535016 returned fine and contained a next_cursor > value of 1267920196862230269. That value returned a 404. > > On Dec 8, 1:32 pm, Ammo Collector wrote: > > > If you get the following URLs and continue to using the next_cursor, > > you receive incorrect 404s: > > >http://twitter.com/statuses/friends/debra_bee.xml?cursor=130554434315... > > > Any ideas?
[twitter-dev] Re: 404 Errors on friends and followers using cursors
Is there an update to the status of this issue? A user of my program reported a problem that ended up being this. While trying to iterate through: http://api.twitter.com/1/statuses/friends/oevl.xml Cursor 1274505087418535016 returned fine and contained a next_cursor value of 1267920196862230269. That value returned a 404. On Dec 8, 1:32 pm, Ammo Collector wrote: > If you get the following URLs and continue to using the next_cursor, > you receive incorrect 404s: > > http://twitter.com/statuses/friends/debra_bee.xml?cursor=130554434315...http://twitter.com/statuses/followers/fraying_ends.xml?cursor=-1http://twitter.com/statuses/followers/Sabrinita_Linda.xml?cursor=-1 > > Any ideas?
[twitter-dev] Re: api.twitter.com SSL issue should be resolved now
Thank you very much for the follow up! Will let you know if I encounter this problem again. On Nov 17, 5:57 pm, Marcel Molina wrote: > After doing some righteous spelunking our ops team discovered a small > misconfiguration that was very likely the culprit of the intermittent > untrusted cert error people were getting when trying to hit > api.twitter.com over SSL. This should be all fixed now. To those who > reported the problem thank you. Please let us know if you still run > into it. We don't think you will be we want to make sure it's totally > fixed. Thanks to everyone who's been patient as we ferreted out this > subtle problem. > > -- > Marcel Molina > Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?
I've been having this same issue when connecting to https://api.twitter.com. I would have thought that if it is a problem with my code, I would always get this error. However, it is intermittent. Most times it works, but a few times an hour I will get the error. Also, I never have this problem with https://twitter.com. On Nov 15, 6:46 pm, John Adams wrote: > On Nov 15, 2009, at 1:16 PM, Tim Haines wrote: > > > Hi there, > > > I'm doing some dev work and I'm getting occasional ssl errors when > > making calls against api.twitter.com/1. The most recent was posting > > to favorites/create. > > > Is it possible some of the servers have bad certificates? Or is it > > likely I'm doing something very wrong? > > All of our servers have the same certificates; We have had some people > report a similar issue before and we verified all of the certificates > at that time. I do know of people having validation issues when they > don't have current versions of OpenSSL, a current Root CA bundle, or > their code has problems processing chained SSL certificates. > > Which program are you using to make requests against api.twitter.com? > curl? Firefox? > > Twitter's SSL certs are issued by RapidSSL/Equifax. > Make sure you have the proper root CA certs installed. > > If you're using OpenSSL libraries directly, remember that OpenSSL > ships without any Root CA certs installed. > > Curl users will have similar problems as well -- you'll want to run mk- > ca-bundle to get the proper ca-bundle installed. > > The TTYtter developers have a script that pulls the current CA bundle > from Mozilla, here: > > http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt > > -john
[twitter-dev] Re: Posting non-English Characters using OAuth
I apologize, I only just saw the responses to this thread. What I ended up having to do was encode the individual bytes if a character is more than one byte. For more details, see this other thread which I replied to: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/ef11efdd0a9cf194/6950ce9721a48609#6950ce9721a48609 On Nov 2, 11:08 am, Duane Roelands wrote: > I'd be very interested in seeing your solution. > > I'm having this very problem in my OAuth implementation and I can't > seem to find a good solution. > > On Nov 2, 7:15 am, Kalpesh wrote: > > > Done! > > It's now updating status successfully for ascii as well as non-ascii > > characters.. > > the problem was my oAuth.. i downloaded the latest code and it's > > working flawlessly.. > > thx for ur help! > > > On Nov 2, 4:27 pm, Kalpesh wrote: > > > > I have tried two things to get my non-english characters status update > > > to work: > > > 1.) Using meta tag in the head as > > content="application/x-www-form-urlencoded; charset=UTF-8" /> > > > 2.) Using utf8_encode for status and posting > > > > None of the above works. I get "incorrect signature" trying to post > > > non-english characters. English characters works fine. > > > I am able to update non-english status with direct status posting from > > > cURL, problem is with oAuth.. > > > Can anyone provide a working example code using oAuth for this? > > > > On Oct 29, 12:35 am, Cameron Kaiser wrote: > > > > > > What encoding function to use for postingnon-englishcharacters ?? > > > > > i am using urlencode but it is not postingnon-englishcharacters to > > > > > twitter > > > > > Are you properly encoding the characters as UTF-8? That should occur > > > > before you URL-encode your payload. > > > > > -- > > > > > > > > personal:http://www.cameronkaiser.com/-- > > > > Cameron Kaiser * Floodgap Systems > > > > *www.floodgap.com*ckai...@floodgap.com > > > > -- The gift of death metal does not smile on the good looking. -- S.B. > > > > #141 ---
[twitter-dev] Re: 401 Unauthorized error while posting status with Unicode characters (non english characters)
Hello, I had this same problem. I had to convert all multi-byte characters into their individual bytes. So, for example, for the character "の": Your example has %306E, but the encoding that works for me is %E3%81%AE (three bytes for the three-byte character). On Sep 25, 5:00 pm, Satheesh Natesan wrote: > Yes, it is UTF-8 encoded. > > The request body for "の脚本家が贈る" is > oauth_consumer_key=wmeO7Y20oMFa1ptKVY4WA&oauth_nonce=3231757&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1253903495&oauth_token=76084396-0M9ll2nghrjWhjALbH7YEHXizcLDNvoLfgXKfHQZQ&oauth_version=1.0&status=%306E%811A%672C%5BB6%304C%8D08%308B&oauth_signature=AMcLsF43vPP6Hmn8fv%2bZCMdqEnU%3d > > and the base signature is > POST&http%3A%2F%2Ftwitter.com%2Fstatuses%2Fupdate.json&oauth_consumer_key%3DwmeO7Y20oMFa1ptKVY4WA%26oauth_nonce%3D3231757%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1253903495%26oauth_token%3D76084396-0M9ll2nghrjWhjALbH7YEHXizcLDNvoLfgXKfHQZQ%26oauth_version%3D1.0%26status%3D%25306E%25811A%25672C%255BB6%25304C%258D08%25308B > > Do you see anything wrong here? > > Thanks! > Satheesh Natesan > > > > On Thu, Sep 24, 2009 at 6:49 PM, Carlos wrote: > > > Are you sure you are encoding your posts as UTF-8? > > > On Sep 24, 5:16 pm, Satheesh Natesan > > wrote: > > > I am getting "401 Unauthorized" exception when updating status with > > > non english characters using my app. > > > > This exception is happening for any Japanese or Korean characters. > > > > Another interesting thing is that it is possible to post some other > > > non english characters like Malayalam. The exception will not happen > > > for single word in these cases, but occurs for multiple words. > > > For example consider the following example > > > > ØáÇÞµæù çµdw - does not work > > > > ØáÇÞµæùçµdw - with space removed works. > > > > Base signature for "ØáÇÞµæù çµdw" which throws exception is > > > > POST&http%3A%2F%2Ftwitter.com%2Fstatuses > > > %2Fupdate.json&oauth_consumer_key% > > > 3DwmeO7Y20oMFa1ptKVY4WA%26oauth_nonce > > > %3D4504682%26oauth_signature_method% > > > 3DHMAC-SHA1%26oauth_timestamp%3D1253727596%26oauth_token%3D76084396- > > > 0M9ll2nghrjWhjALbH7YEHXizcLDNvoLfgXKfHQZQ%26oauth_version > > > %3D1.0%26status% > > > 3D%25D8%25E1%25C7%25DE%25B5%25E6%25F9%2520%25E7%25B5dw > > > > and for "ØáÇÞµæùçµdw" which works is > > > > POST&http%3A%2F%2Ftwitter.com%2Fstatuses > > > %2Fupdate.json&oauth_consumer_key% > > > 3DwmeO7Y20oMFa1ptKVY4WA%26oauth_nonce > > > %3D9388868%26oauth_signature_method% > > > 3DHMAC-SHA1%26oauth_timestamp%3D1253727793%26oauth_token%3D76084396- > > > 0M9ll2nghrjWhjALbH7YEHXizcLDNvoLfgXKfHQZQ%26oauth_version > > > %3D1.0%26status% > > > 3D%25D8%25E1%25C7%25DE%25B5%25E6%25F9%25E7%25B5dw > > > > OAuth client library I am using is in .Net > > > > Could you please help to solve this issue? Also I would like to know > > > you support all unicode characters. > > > Your help is greatly appreciated. > > > > Thanks, > > > Satheesh Natesan- Hide quoted text - > > - Show quoted text -
[twitter-dev] Re: Posting non-English Characters using OAuth
Thanks for the response, Brian :) After a bit more debugging and research, I found the problem. In hindsight it's obvious, but I was putting too much faith into how the characters were being encoded. That "%65E5%672C%72AC" was completely incorrect, and instead the individual bytes needed to be encoded and sent to twitter. Once I changed the oAuth code to do that, it's working flawlessly. Thanks again for your response! On Sep 18, 2:59 pm, "Brian Smith" wrote: > Mageuzi wrote: > > I'm sorry for posting a follow up so soon, but I spent another few > > hours trying to debug this again last night, and still without > > success. It seems to be encoding the characters properly (%65E5%672C > > %72AC in this case), and so I assume it is generating the signature > > properly. After all, it works perfectly fine with English characters. > > So any guidance would be much appreciated, I'm running out of things > > to check. > > > Thank you again in advance. > > It probably isn't generating the signature properly. Try using a different > library to post the same message and likely you will find that they are > calculating the signature differently. Calculating bad signatures for > non-ASCII characters is probably the most common bug in OAuth libraries, > because the authors often test with ASCII characters but not non-ASCII > characters. If the library you are using has a mechanism for you to get the > signature base string, use that mechanism to retrieve it and post it here. > > Also, try using a different OAuth library. > > がんばってください! > > - Brian
[twitter-dev] Re: Posting non-English Characters using OAuth
Hello again, I'm sorry for posting a follow up so soon, but I spent another few hours trying to debug this again last night, and still without success. It seems to be encoding the characters properly (%65E5%672C %72AC in this case), and so I assume it is generating the signature properly. After all, it works perfectly fine with English characters. So any guidance would be much appreciated, I'm running out of things to check. Thank you again in advance. On Sep 16, 9:45 pm, Mageuzi wrote: > Hello, > I was hoping someone could help me, or point me in the right > direction. > > I've written an app that used basic auth for a while, and of course > that worked great. I'm now working on switching to OAuth, and > everything worked perfectly until I tried posting a status update that > used non-English characters, such as the following Japanese: > > 日本犬 > > In this case, I get a 401 Unauthorized error. I've looked at the > signature and the encoding of the parameters, and it appears as if > everything is being processed correctly, but it's possible I missed > something. > > I'm using C#, and the OAuth implementation I'm using can be found > here:http://www.voiceoftech.com/swhitley/?p=681 > > The only changes made to that code involve adding support for the PIN > when first authorizing an account, but that isn't relevant to this. > > Any help would be much appreciated, I'm not sure what to try at this > point.
[twitter-dev] Posting non-English Characters using OAuth
Hello, I was hoping someone could help me, or point me in the right direction. I've written an app that used basic auth for a while, and of course that worked great. I'm now working on switching to OAuth, and everything worked perfectly until I tried posting a status update that used non-English characters, such as the following Japanese: 日本犬 In this case, I get a 401 Unauthorized error. I've looked at the signature and the encoding of the parameters, and it appears as if everything is being processed correctly, but it's possible I missed something. I'm using C#, and the OAuth implementation I'm using can be found here: http://www.voiceoftech.com/swhitley/?p=681 The only changes made to that code involve adding support for the PIN when first authorizing an account, but that isn't relevant to this. Any help would be much appreciated, I'm not sure what to try at this point.
