[twitter-dev] Re: R/W/DM app update not shown in app auth
Hi, You are probably the victim of a design singularity, that was documented in a FAQ (yes, a FAQ) I assume your application is using the oauth/authenticate url Replace authenticate with authorize and you should be fine. Accessing DM is not possible when using authenticate, for some reason On 5 juil, 22:31, oosswwaalldd oosswwaal...@gmail.com wrote: Hi, I al ready upgraded my app from R/W to R/W/DM, that was june 30th, but still when a user enter to my site and it is re-directed to the Twitter grant access page, the app page says that my app won't have access to the user DMs, is there a problem with Twitter database or should I miss a step. Tha app works fine but every day-day and a half I have to tell the users to revoke and re-authorize my app in order to work properly again. Thanks in advance -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Re: Chinese Character
Hi Zhe Chen Here at Yoono we do have a lot of Chinese users and we use the Twitter API with no issue at all. Just make sure you are using UTF-8 encoding, especially when computing OAuth signatures On 26 jan, 23:59, Zhe Chen chenzhe@gmail.com wrote: Does twitter stream API support Chinese character? -- 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: Snowflake: An update and some very important information
What's the point? That would still require a change in the JSON output, to replace integers with strings. On 21 oct, 15:38, David Nicol davidni...@gmail.com wrote: Unless I did the math wrong, a 64 bit quantity is expressable in (64 * log(2)) / log(62) = 10.7487219 eleven characters drawn from A-Za-z0-9 and they can still be sortable! -- 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: Snowflake: An update and some very important information
Hi
In the case where an id is null (as in in_reply_to_status_id:null )
what will the value of in_reply_to_status_id_str be ?
Thanks
Xavier
On 19 oct, 02:34, themattharris thematthar...@twitter.com wrote:
Thanks to @gotwalt for spotting the missing commas.
Fixed JSON sample ...
[
{
coordinates: null,
truncated: false,
created_at: Thu Oct 14 22:20:15 + 2010,
favorited: false,
entities: {
urls: [
],
hashtags: [
],
user_mentions: [
{
name: Matt Harris,
id: 777925,
id_str: 777925,
indices: [
0,
14
],
screen_name: themattharris
}
]
},
text: @themattharris hey how are things?,
annotations: null,
contributors: [
{
id: 819797,
id_str: 819797,
screen_name: episod
}
],
id: 12738165059,
id_str: 12738165059,
retweet_count: 0,
geo: null,
retweeted: false,
in_reply_to_user_id: 777925,
in_reply_to_user_id_str: 777925,
in_reply_to_screen_name: themattharris,
user: {
id: 6253282,
id_str: 6253282
},
source: web,
place: null,
in_reply_to_status_id: 12738040524,
in_reply_to_status_id_str: 12738040524
}
]
Best,
@themattharris
On Oct 18, 5:19 pm, Matt Harris thematthar...@twitter.com wrote:
Last week you may remember Twitter planned to enable the new Status ID
generator - 'Snowflake' but didn't. The purpose of this email is to explain
the reason why this didn't happen, what we are doing about it, and what the
new release plan is.
So what is Snowflake?
--
Snowflake is a service we will be using to generate unique Tweet IDs. These
Tweet IDs are unique 64bit unsigned integers, which, instead of being
sequential like the current IDs, are based on time. The full ID is composed
of a timestamp, a worker number, and a sequence number.
The problem
-
Before launch it came to our attention that some programming languages such
as Javascript cannot support numbers with 53bits. This can be easily
examined by running a command similar to: (90071992547409921).toString() in
your browsers console or by running the following JSON snippet through your
JSON parser.
{id: 10765432100123456789, id_str: 10765432100123456789}
In affected JSON parsers the ID will not be converted successfully and will
lose accuracy. In some parsers there may even be an exception.
The solution
To allow javascript and JSON parsers to read the IDs we need to include a
string version of any ID when responding in the JSON format. What this means
is Status, User, Direct Message and Saved Search IDs in the Twitter API will
now be returned as an integer and a string in JSON responses. This will
apply to the main Twitter API, the Streaming API and the Search API.
For example, a status object will now contain an id and an id_str. The
following JSON representation of a status object shows the two versions of
the ID fields for each data point.
[
{
coordinates: null,
truncated: false,
created_at: Thu Oct 14 22:20:15 + 2010,
favorited: false,
entities: {
urls: [
],
hashtags: [
],
user_mentions: [
{
name: Matt Harris,
id: 777925,
id_str: 777925,
indices: [
0,
14
],
screen_name: themattharris
}
]
},
text: @themattharris hey how are things?,
annotations: null,
contributors: [
{
id: 819797,
id_str: 819797,
screen_name: episod
}
],
id: 12738165059,
id_str: 12738165059,
retweet_count: 0,
geo: null,
retweeted: false,
in_reply_to_user_id: 777925,
in_reply_to_user_id_str: 777925,
in_reply_to_screen_name: themattharris,
user: {
id: 6253282
id_str: 6253282
},
source: web,
place: null,
in_reply_to_status_id: 12738040524
in_reply_to_status_id_str: 12738040524
}
]
What should you do - RIGHT NOW
--
The first thing you should do is attempt to decode the JSON snippet above
using your production code parser. Observe the output to confirm the ID has
not lost accuracy.
What you do next depends on what happens:
* If your code converts the ID successfully without losing accuracy you are
OK but should consider converting to the _str versions of IDs as soon as
possible.
* If your code has lost accuracy, convert your code to using the _str
version immediately. If you do not do this your code will be unable to
interact with the Twitter API reliably.
* In some language parsers, the
[twitter-dev] Re: 401 Unauthorized problem
I have the same problem. I've tried to not include the _method param from signature computing, didn't work any better. On Dec 3, 11:13 am, Wilfred yau wld991...@gmail.com wrote: I have try that put the _method=DELETEin Header, but still not work... do anyone know if it is Twitter API bug or it is my problem... this problem stop the development of my new Twitter Client in Firefox... Thanks Wilfred
[twitter-dev] DELETE /:user/:list_id/subscribers in OAuth with POST and _method=DELETE
Has anyone succeeded in making this work ? What am I doing wrong, I get a 401 unauthorized response... Thanks for your help !
[twitter-dev] Re: Typo in delete list subscribers documentation
Agreed too. Was anyone able to make it work using a OAuth POST request with _method = DELETE additional parameter ? Should _method be included in the OAuth signature ? (both fail for me) Thanks On Dec 10, 9:46 pm, Orian Marx (@orian) or...@orianmarx.com wrote: Agreed. On Dec 10, 3:38 pm, Abraham Williams 4bra...@gmail.com wrote: If only some of the community could be involved in updating the wiki this could be fixed already. Abraham On Wed, Dec 9, 2009 at 19:51, Orian Marx (@orian) or...@orianmarx.comwrote: In the DELETE list subscribers documentation ( http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-DELETE-list-sub... ) the URL for the service is http://api.twitter.com/1/user/list_id/members.format but I think it's supposed to be http://api.twitter.com/1/user/list_id/subscribers.format -- Abraham Williams | Community Evangelist |http://web608.org Project | Intersect |http://intersect.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: 401 Unauthorized problem
I submitted a bug, vote for it: http://code.google.com/p/twitter-api/issues/detail?id=1294colspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component On Dec 3, 11:13 am, Wilfred yau wld991...@gmail.com wrote: I have try that put the _method=DELETEin Header, but still not work... do anyone know if it is Twitter API bug or it is my problem... this problem stop the development of my new Twitter Client in Firefox... Thanks Wilfred On Nov 27, 1:24 pm, Mark McBride mmcbr...@twitter.com wrote: It looks like you're trying to actually include the OAuth Authorization header in your POST body, which isn't the way you want to do it. Instead, you should be using the Authorization HTTP header to transmit this info (seehttp://oauth.net/core/1.0a#anchor46). To make things extra weird, in one case you do have an Authorization header set, but it's basic auth. ---Mark On Thu, Nov 26, 2009 at 6:47 PM, Wilfred yau wld991...@gmail.com wrote: I have already solve the special char problem because encoding in Flex. but I still find that when I call _method=DELETEinListAPI, I still get401Unauthorized from api.twitter.com. On Nov 25, 11:09 am, Wilfred yau wld991...@gmail.com wrote: I am using OAuth to accessListAPI, but I find that if the request URL contain some char like _, (, then twitter will return 401 Unauthorized. Does anyone know what is the problem?? and this is my request: *Request URL: http://api.twitter.com/1/wilfred_yau/yedsrc/members.xml *Request header: Host:api.twitter.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: 1.9.2b3) Gecko/20091115 Firefox/3.6b3 GTB6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: __utma=43838368.448377351.1258538849.1259115844.1259117264.22; __utmz=43838368.1258703218.9.4.utmcsr=google|utmccn=(organic)| utmcmd=organic|utmctr=gmasbaby; __utmv=43838368.lang%3A%20en; __qca=P0-1731751766-1258598366235; __utmb=43838368.8.10.1259117264; _twitter_sess=BAh7DDoTcGFzc3dvcmRfdG9rZW4iLWYxZDlkMzA5OWExZTMxMDIzZTlmMGJj %250AOWM1YzllYzAyYTVjOWU2NGM6DGNzcmZfaWQiJTU4MTVlMjgzNWUyNGNhYThh %250ANjE1YzdjOWU4MTE5MGJjOhF0cmFuc19wcm9tcHQwOgl1c2VyaQQ5oOgDOg5y %250AZXR1cm5fdG8iJGh0dHA6Ly90d2l0dGVyLmNvbS9zb2Z0cGVkaWFtYWM6B2lk %250AIiU0Y2JmMWJmNjc0YzJmOTlhZGZjMTA1MzE3NzI3ZGUwNiIKZmxhc2hJQzon %250AQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7%250AAA %253D%253D--3573176707558a7f9cd9653e6a60c073c94e91f5; __utmc=43838368 *Post Data: Content-type: application/x-www-form-urlencoded Content-length: 300 oauth%5Fconsumer%5Fkey=WiW3RrjmAhPvWvTn6oPLAid=66626470oauth %5Ftoken=65577017%2DK65DjHAcUbYOEJW5XMVnVuAkRy8fDnNnVGRZDOSAQoauth %5Ftimestamp=1259118273oauth%5Fsignature=zaA0CbWpls3lowiWG0yHCZig%2B2M %3Doauth%5Fversion=1%2E0oauth%5Fsignature%5Fmethod=HMAC%2DSHA1 %5Fmethod=DELETEoauth%5Fnonce=2875 Also, I got same problem in set status using OAuth : *Request URL: http://twitter.com/statuses/update.xml *Request header: Host: twitter.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: 1.9.2b3) Gecko/20091115 Firefox/3.6b3 GTB6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: __utma=43838368.448377351.1258538849.1259115844.1259117264.22; __utmz=43838368.1258703218.9.4.utmcsr=google|utmccn=(organic)| utmcmd=organic|utmctr=gmasbaby; __utmv=43838368.lang%3A%20en; __qca=P0-1731751766-1258598366235; __utmb=43838368.8.10.1259117264; _twitter_sess=BAh7DDoTcGFzc3dvcmRfdG9rZW4iLWYxZDlkMzA5OWExZTMxMDIzZTlmMGJj %250AOWM1YzllYzAyYTVjOWU2NGM6DGNzcmZfaWQiJTU4MTVlMjgzNWUyNGNhYThh %250ANjE1YzdjOWU4MTE5MGJjOgl1c2VyaQQ5oOgDOhF0cmFuc19wcm9tcHQwIgpm %250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG %250AOgpAdXNlZHsAOgdpZCIlNGNiZjFiZjY3NGMyZjk5YWRmYzEwNTMxNzcyN2Rl %250AMDY6DnJldHVybl90byIkaHR0cDovL3R3aXR0ZXIuY29tL3NvZnRwZWRpYW1h %250AYw%253D%253D--dfa30d93e80be97e1404abbb466f2c6191816d69; __utmc=43838368 Authorization: Basic Z21hc2JhYnk6eW95b2JhYnk= *Post Data: Content-type: application/x-www-form-urlencoded Content-length: 303 oauth%5Fnonce=4280oauth%5Fsignature%5Fmethod=HMAC%2DSHA1oauth %5Ftimestamp=1259117789status=%40vincenthpchan%20%28O%3Aoauth %5Fversion=1%2E0oauth%5Fconsumer%5Fkey=WiW3RrjmAhPvWvTn6oPLAoauth %5Fsignature=dZ0OBySJzAZsdhwUKvK9zaIamE4%3Doauth %5Ftoken=65577017%2DK65DjHAcUbYOEJW5XMVnVuAkRy8fDnNnVGRZDOSAQ I wonder it is the problem about oauth_signature, but I don't what wrong with it. Thanks
[twitter-dev] Re: Counter for rate limit remaining requests unreliable, often reaches 0 unduly
I wish someone could just check this matter. I can provide an XML file showing all ordered requests (with all params, responses, etc) with the dumb counter values showing up. Thanks Xavier On Sep 4, 11:37 am, Reivax xavier.yo...@gmail.com wrote: All requests are done authentified. Thanks Xavier On Sep 4, 11:26 am, fbparis fbou...@gmail.com wrote: According to the last api request you've done, X-RateLimit-Remaining can be user limit or IP limit (depends if you made an authentified request or not). This can explain the X-RateLimit-Remaining values you've posted. On Sep 4, 11:03 am, Reivax xavier.yo...@gmail.com wrote: I'm having this problem for a few days, and I've been monitoring ALL requests sent to twitter, here is what I saw : The value of the X-RateLimit-Remaining header is totally unreliable. For instance, the response to a request will have it at 120, while the next response will have it at 40. Then subsequent request responses will have values such as 118, 39, 37, 36, 117, ... and so on. All responses have the same X-RateLimit-Reset ! It all looks like there are 2 unsynchronized counters, and responses get values from either one of them... The trouble is that one counter reaches 0 much too early, which makes my twitter client says the maximum allowed request has been reached !! I make 3 requests every 2 minutes, so I should never reach the max. I have the exact same behavior when using the rate_limit_status request. I made sure I have no other client on that account, and I can reproduce the problem each time. Even if I had, there would not be cases where it goes from 36 to 117 for 2 adjacent requests... Thanks for looking into that ! (I can provide traces of the requests) Regards, Xavier
[twitter-dev] Re: Counter for rate limit remaining requests unreliable, often reaches 0 unduly
Hey Richard, If you get a chance to put a proxy to display all requests going out of TweetDeck, you'll easily see that 'remaining' counters sent back by twitter go wild often enough. Chances are TweetDeck users blame it on TweetDeck :( Thanks for your feedback, let's hope that will help make twitter dev team work on that critical issue Xavier On Sep 8, 10:47 am, Richard richardbar...@gmail.com wrote: I've seen many many reports of this coming in to TweetDeck support. Rate limit exceeded when it's not really. On Sep 8, 9:26 am, Reivax xavier.yo...@gmail.com wrote: I wish someone could just check this matter. I can provide an XML file showing all ordered requests (with all params, responses, etc) with the dumb counter values showing up. Thanks Xavier On Sep 4, 11:37 am, Reivax xavier.yo...@gmail.com wrote: All requests are done authentified. Thanks Xavier On Sep 4, 11:26 am, fbparis fbou...@gmail.com wrote: According to the last api request you've done, X-RateLimit-Remaining can be user limit or IP limit (depends if you made an authentified request or not). This can explain the X-RateLimit-Remaining values you've posted. On Sep 4, 11:03 am, Reivax xavier.yo...@gmail.com wrote: I'm having this problem for a few days, and I've been monitoring ALL requests sent to twitter, here is what I saw : The value of the X-RateLimit-Remaining header is totally unreliable. For instance, the response to a request will have it at 120, while the next response will have it at 40. Then subsequent request responses will have values such as 118, 39, 37, 36, 117, ... and so on. All responses have the same X-RateLimit-Reset ! It all looks like there are 2 unsynchronized counters, and responses get values from either one of them... The trouble is that one counter reaches 0 much too early, which makes my twitter client says the maximum allowed request has been reached !! I make 3 requests every 2 minutes, so I should never reach the max. I have the exact same behavior when using the rate_limit_status request. I made sure I have no other client on that account, and I can reproduce the problem each time. Even if I had, there would not be cases where it goes from 36 to 117 for 2 adjacent requests... Thanks for looking into that ! (I can provide traces of the requests) Regards, Xavier
[twitter-dev] Counter for rate limit remaining requests unreliable, often reaches 0 unduly
I'm having this problem for a few days, and I've been monitoring ALL requests sent to twitter, here is what I saw : The value of the X-RateLimit-Remaining header is totally unreliable. For instance, the response to a request will have it at 120, while the next response will have it at 40. Then subsequent request responses will have values such as 118, 39, 37, 36, 117, ... and so on. All responses have the same X-RateLimit-Reset ! It all looks like there are 2 unsynchronized counters, and responses get values from either one of them... The trouble is that one counter reaches 0 much too early, which makes my twitter client says the maximum allowed request has been reached !! I make 3 requests every 2 minutes, so I should never reach the max. I have the exact same behavior when using the rate_limit_status request. I made sure I have no other client on that account, and I can reproduce the problem each time. Even if I had, there would not be cases where it goes from 36 to 117 for 2 adjacent requests... Thanks for looking into that ! (I can provide traces of the requests) Regards, Xavier
[twitter-dev] Re: Counter for rate limit remaining requests unreliable, often reaches 0 unduly
All requests are done authentified. Thanks Xavier On Sep 4, 11:26 am, fbparis fbou...@gmail.com wrote: According to the last api request you've done, X-RateLimit-Remaining can be user limit or IP limit (depends if you made an authentified request or not). This can explain the X-RateLimit-Remaining values you've posted. On Sep 4, 11:03 am, Reivax xavier.yo...@gmail.com wrote: I'm having this problem for a few days, and I've been monitoring ALL requests sent to twitter, here is what I saw : The value of the X-RateLimit-Remaining header is totally unreliable. For instance, the response to a request will have it at 120, while the next response will have it at 40. Then subsequent request responses will have values such as 118, 39, 37, 36, 117, ... and so on. All responses have the same X-RateLimit-Reset ! It all looks like there are 2 unsynchronized counters, and responses get values from either one of them... The trouble is that one counter reaches 0 much too early, which makes my twitter client says the maximum allowed request has been reached !! I make 3 requests every 2 minutes, so I should never reach the max. I have the exact same behavior when using the rate_limit_status request. I made sure I have no other client on that account, and I can reproduce the problem each time. Even if I had, there would not be cases where it goes from 36 to 117 for 2 adjacent requests... Thanks for looking into that ! (I can provide traces of the requests) Regards, Xavier
[twitter-dev] Re: Search API Rate Limiting and Performance
John, the original message of this thread is about rate limit being totally erratic, as several users have noticed. here is the detail of what I'm seeing: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/40c82b4dbc0536bd Here is another user reporting the problem : http://groups.google.com/group/twitter-development-talk/browse_thread/thread/51bd6667d3b0a0a6 Basically the X-RateLimit-Remaining header goes up and down and up again between adjacent requests (all authenticated requests). The result is that the limit can appear to be reached way before 150 requests were issued... Thanks On Sep 4, 6:30 pm, John Kalucki jkalu...@gmail.com wrote: The Search team is working on indexing latency and throughput, along with a many other things. There have been big improvements recently and more are on the way. In the mean time, if you need closer to real-time results, consider the track parameter on the Streaming API. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 4, 6:58 am, pxpilot pxpi...@gmail.com wrote: Search API will rock if it would only be reliable what we see looks to be some sort of a funky cache, a query (atom) can be missing some latest tweets and then after a while they show up, if you tweak the query you can see 'em. you ever seen this problem? also what did you do special with user agent? On Sep 2, 12:12 pm, Amitab hiamita...@gmail.com wrote: I have exchanged emails with Twitter on this and I believe they are working on it. We use search extensively atwww.Twaller.com. The errors in search that we are seing is as follows: (1) HTTP status code: 403 Message:The request is understood, but it has been refused. An accompanying error message will explain why. (2)HTTP status code: 503 Message:Service Unavailable: The Twitter servers are up, but overloaded with requests. Try again later. The search and trend methods use this to indicate when you are being rate limited. (3) HTTP status code: -1 Message:Read timed out These errors are becoming more and more frequent lately. /Amitab On Sep 1, 5:41 pm,Dewald Pretoriusdpr...@gmail.com wrote: Twitter team, can you please do something about the performance and rate limiting of the Search API. It is becoming completely unworkable. I have jumped through all the hoops, with unique User Agents, sleeping my scripts in-between API calls, and yet the rate limiting is just becoming more severe, and the performance is just becoming slower and slower. Please help. A lot of us are using Search to provide services, and I am sure it is not only my service that is hurting very much under the present circumstances. Dewald
