Re: [twitter-dev] Retweets of me...

[Christian Schlimmer]

Maybe you'll like this new parameter in some timeline methods (ex:
"statuses/user_timeline"): "include_rts=true"

Source: 
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/7a4be385ff549ed0/

[quote]
New opt-in API features available today, May 26th: entities, retweets
in timelines, custom oauth_callback schemes
...
 *Retweets in Timelines*
*
*Many developers have asked for merged timelines including native retweets;
for backwards-compatibility reasons this hasn't been possible in the past.
Now you can include a include_rts=true parameter to statuses/user_timeline,
statuses/friends_timeline, and statuses/mentions API calls to receive
retweets inline in the payload.
[/quote]

[twitter-dev] Re: Recent Places-related API enhancements & more to come...

[Joe Critchley]

Hi,

In terms of both technicalities and appropriate semantics,
will it be ok to use the attached 'place' to
annotate past or future places, as well as the present location?

This could play a key part in my development, so any help would be
great. Thanks.

On Jun 14, 7:43 pm, Taylor Singletary 
wrote:
> Hi Developers,
>
> Today we're launching some of the functionality around "Places" that we
> announced at Chirp. You can read more about the feature 
> here:http://blog.twitter.com/2010/06/twitter-places-more-context-for-your
>
> The launch comes with a batch of API enhancements, with a number of further
> API additions just around the corner (like creating and updating places,
> obviously a crucial component for many implementors).
>
> The documentation in this area is a honestly a bit light at the moment, but
> we'll be offering some more comprehensive documentation going over suggested
> use cases, flows, and more in the coming days.
>
> What matters most for you:
>   - GET geo/nearby_places is now GET geo/search, with some added
> functionality. This is a companion to GET geo/reverse_geocode, that's ideal
> for using in conjunction with a place selection UI.
>     Read all about it at :http://bit.ly/dvNmYB
>     - A query parameter called "query" lets you do textual matching when
> trying to find a place
>     - A query parameter called "ip" lets you do a lookup based on an IP
> address
>     - You can fine tune results with granularity, accuracy, and the
> contained_within parameter, which allows you to identify a place_id
> (matching something like a city), and only search for places within that
> place.
>
>   -  tags in XML output, "place" attribute in JSON output:
>
> Tweets that have a place_id associated with them can now contain some
> additional information not available in the past, including some attributes
> that further describe the location.
>
> Some common place/attributes you might start seeing:
>   - name
>   - street_address
>   - locality
>   - region
>   - phone
>   - postal_code
>   - twitter (a twitter account associated with the place)
>   - cross_streets
>
> Attribute key names can be variant. These are just some of the attribute
> keys you will see, with much more to come.
>
>     Here's a quick XML representation of a status with a place:
>     
>       Mon Jun 14 23:30:14+ 2010
>       16184038366
>       I'm testing out places integrations. Can you hear me Planet
> Houston? I'm at the Epicenter. (psyche)
>       web
>       false
>       
>       
>       false
>       
>       
>         819797
>         Taylor Singletary
>         episod
>         iPhone:37.778181,-122.397971
>         Reality Technician, Developer Advocate at Twitter,
> displeased at Planet Houston
>         
> http://a1.twimg.com/profile_images/989643540/zod_normal.jpg
> 
>         http://bit.ly/5w7P88
>         false
>         1461
>         00
>         00
>         731673
>         007ffe
>         bb0e79
>         1420
>         Wed Mar 07 22:23:19+ 2007
>         254
>         -28800
>         Pacific Time (US & Canada)
>         
> http://a3.twimg.com/profile_background_images/19651315/fiberoptics.jpg
> 
>         true
>         false
>         true
>         false
>         false
>         6477
>         en
>         false
>       
>       
>       
>       http://www.georss.org/georss";>
>         a851ec943d3a27c5
>         Epicenter Cafe
>         Epicenter Cafe, San Francisco
>         poi
>         http://api.twitter.com/1/geo/id/a851ec943d3a27c5.json
>         
>           
>             street_address
>             764 Harrison St
>           
>         
>         
>           37.781343 -122.399142 37.781343 -122.399142
> 37.781343 -122.399142 37.781343 -122.399142
>         
>         The United States of America
>       
>       
>       
>     
>
>     And here's the JSON representation:
>     {
>         "in_reply_to_user_id": null,
>         "geo": null,
>         "source": "web",
>         "created_at": "Mon Jun 14 23:30:14+ 2010",
>         "place": {
>             "place_type": "poi",
>             "country_code": "US",
>             "attributes": {
>                 "street_address": "764 Harrison St"
>             },
>             "country": "The United States of America",
>             "full_name": "Epicenter Cafe, San Francisco",
>             "url": "http://api.twitter.com/1/geo/id/a851ec943d3a27c5.json";,
>             "name": "Epicenter Cafe",
>             "id": "a851ec943d3a27c5",
>             "bounding_box": {
>                 "type": "Polygon",
>                 "coordinates": [[[ -122.399142,37.781343], [ 
> -122.399142,37.781343], [ -122.399142,37.781343], [ -122.399142,37.781343]]]
>             }
>         },
>         "in_reply_to_screen_name": null,
>         "favorited": false,
>         "truncated": false,
>         "annotations": null,
>         "user": {
>             "profile_background_image_url": 
> "http://a3.twimg.com/profile_backgro

[twitter-dev] incorrect signatures

[Udi]

we recently (24-48 hours ago) started getting "incorrect signature"
errors for some of our users. accessing the twitter api with the same
software and the same auth data from a different location works fine.
for one user there were only issues with home_timeline.json but
user_timeline.json worked fine.

any ideas?

thanks,
udi

[twitter-dev] Re: since_id confusion

[Terence Eden]

To make this slightly clearer Imagine I have retrieved a page with
20 statuses.  Status IDs are

60 ... 40

Calling the timeline with max_id=40&count=20 allows me to step back in
time.  It gives me

40 ... 20

Suppose I just want to see *next* 20 tweets since status_id 60?
I would expect calling the timeline with since_id=60&count=20 to give
me

80 ... 60

It doesn't.  It gives me
100 ... 80.
That is, the 20 most recent tweets from *now*.  I want the reverse of
that.  The 20 tweets from *since_id*.

Is there any way to get that?  I don't want to call the 200 most
recent tweets and try to find the 20 I'm looking for, partly on
bandwidth & processing grounds, but also, if the user is, say, 300
tweets deep into their timeline, they'll miss tweets.

Thanks

Terence

On Jun 26, 3:52 pm, Terence Eden  wrote:
> Am I mistaken in how since_id works?
>
> Callinghttp://api.twitter.com/1/statuses/home_timeline.json?count=20&max_id=...
> Gives me the *next* 20 tweets from 1234
>
> However, calling with 
> since_idhttp://api.twitter.com/1/statuses/home_timeline.json?count=20&since_i...
> Gives me the *first* 20 tweets in the timeline.  I was expecting it to
> show the 20 tweets *from* 1234
>
> Am I the only one with this confusion? Or is there a better way to
> just retrieve the first 20 tweets which have occurred since?
>
> Thanks
>
> T
> (Essentially, I'm implementing older and newer buttons which always
> show older/newer tweets, rather than pages.)

[twitter-dev] i want to develop symbian c++ application which will send message on twitter using https request

[rahul makode]

hi all,

i want to develop symbian c++ application which will send message on
twitter using https request,

if any body have done this plz suggest me path

bye

[twitter-dev] Re: abrahams twitteroauth issue

[Rick]

Hello,

Is it even possible to use abrahams twitteroauth library to get all
the followers the way I want it. I screwed up and now I must rewrite
the cursor idea, Is anybody having a example code for the abrahams
twitteroauth.

Thank you

On 25 jun, 21:50, Sam Wierema  wrote:
> Yes, it's very possible. Haven't tested it, but it should be something
> like this:
>
> $cursor = -1;
> while( $cursor !== 0 ) {
>     $info = $oauth->get( 'statuses/followers', array( 'cursor' =>
> $cursor ) );
>     if( $oauth->http_code === 200 && !isset( $info->error ) ) {
>         // Count or whatever here
>         $cursor = $info->next_cursor;
>     }
>
> }
>
> If you just want to count all of your followers, why not do users/
> show? That contains a followers_count variable in it.
>
> On Jun 25, 4:18 pm, Rick  wrote:
>
> > Thank you for your reply.
>
> > I don't use next_cursor or whatsoever. I just use the $followers
> > variable to use count it with $totaal = count($followers); so I can
> > use it in my code. The cursor code I posted before is the only thing I
> > use to try and get information.
>
> > Is it even possible to get all the followers with the abrahams twitter
> > library?
>
> > On 25 jun, 15:11, Sam Wierema  wrote:
>
> > > You should not increment your cursor, because Twitter returns a cursor
> > > for you. And if cursor is 0, it means that there are no more pages (-1
> > > + 1 = 0).
>
> > > Check your $followers variable that you got from the first call. It
> > > should be called something like next_cursor.
>
> > > On Jun 25, 2:26 pm, Rick  wrote:
>
> > > > Howdy!
>
> > > > I am currently making my application OAuth compatible from basic auth,
> > > > currently I have a issue I need to get resolved in order to switch to
> > > > the new OAuth method.
>
> > > > I am getting my followers from: $oauth->get('statuses/followers'); but
> > > > that only gives me the last 100 followers, I trought it would be easy
> > > > to do it this way:
>
> > > > $cursor = -1;
> > > > $followers = $oauth->get('statuses/followers', array('cursor' =>
> > > > $cursor));
> > > > // Other code here..
>
> > > > $cursor++;
> > > > $followers = $oauth->get('statuses/followers', array('cursor' =>
> > > > $cursor));
>
> > > > Is it possible to get all my users, because this code does not work
> > > > and my inspiration was wrong.
>
> > > > Hopefully you can help me.
>
> > > > Regards,
>
> > > > Rick

Re: [twitter-dev] Retweets of me...

[Harshad RJ]

On Mon, Jun 28, 2010 at 4:05 AM, Christian Schlimmer <
christian.schlim...@googlemail.com> wrote:

> Maybe you'll like this new parameter in some timeline methods (ex:
> "statuses/user_timeline"): "include_rts=true"
>
>
Thanks for the info, but I can't see how this would be useful to find
"retweets of me" with one API call.

-- 
Harshad RJ
http://hrj.wikidot.com

RE: [twitter-dev] Statuses getting lost when user is not logged

[eliamara andreatta thompsom]

From: taylorsinglet...@twitter.com
Date: Mon, 21 Jun 2010 12:10:18 -0700
Subject: Re: [twitter-dev] Statuses getting lost when user is not logged
To: twitter-development-talk@googlegroups.com

This should be fixed soon.. (hopefully today even) 
You can follow the bug here. 
http://code.google.com/p/twitter-api/issues/detail?id=1650&q=logged%20out&colspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component




On Mon, Jun 21, 2010 at 11:59 AM, dirs  wrote:


Hi,



I've a RT widget and use "http://twitter.com/home/?status="; to send

user to twitter with the tweetbox with content. Works great, but when

user aren't logged Twitter seems to didn't redirect the "status"

parameter.



I think that this happened before.



thxbye


  
_
QUER FICAR SEMPRE EM CONTATO COM SEUS AMIGOS? ACESSE O MESSENGER PELO SEU 
CELULAR.
http://celular.windowslive.com.br/messenger.asp?produto=Messenger&utm_source=Live_Hotmail&utm_medium=Tagline&utm_content=QUERFICARS82&utm_campaign=MobileServices

[twitter-dev] When will be supported UTF-8 encoding support in Twitter Streaming API?

[sjoonk]

I know current Twitter Streaming API do not support utf-8 track
keyword.
As an CJK engineer, I hope this feature will implemented so soon.
Does anybody know when will be supported this feature in Twitter
Streaming API??

Re: [twitter-dev] When will be supported UTF-8 encoding support in Twitter Streaming API?

[John Kalucki]

We don't have current plans to fix this issue. The problem isn't around
utf-8, but rather around non-space separated languages. Our language
processing experts described the effort required, and it's a pretty large
project, and may be computationally impractical in the current streaming
architecture. There is a workaround, albeit a generally impractical one:
take the firehose and perform the language parsing on your end.

-John Kalucki
http://twitter.com/jkalucki
Twitter Inc.


On Mon, Jun 28, 2010 at 1:34 AM, sjoonk  wrote:

> I know current Twitter Streaming API do not support utf-8 track
> keyword.
> As an CJK engineer, I hope this feature will implemented so soon.
> Does anybody know when will be supported this feature in Twitter
> Streaming API??
>

[twitter-dev] Using OAuth with twitter mobile

[virus]

Hello developers,
I'm a new user of OAuth and twitter both :). I need to develop a web
application which is able to authenticate a user using OAuth. What I
want is that the authorization page opens up as a mobile website page
and not like one with a Desktop application. Much like Facebook mobile
in which we can add a "display=wap" url variable to the authorize
page.

How can I do this with twitter mobile. Please help me out, I'm in a
pickle here...

Re: [twitter-dev] Transitioning from Basic Auth to OAuth Guide (need your help!)

[Taylor Singletary]

Thanks for the tips, Andrew!

Your suggestions to Apple on secret management seems like a great idea.
We'll keep that on our radar.

Taylor

On Fri, Jun 25, 2010 at 2:57 PM, Andrew W. Donoho
wrote:

>
> On Jun 25, 2010, at 15:42 , Taylor Singletary wrote:
>
> > However, we'd love to collect together specific implementation stories of
> developers who've successfully made the transition and highlight them here.
>
>
>
>
> Taylor et. al.,
>
>As someone with his own custom iPhone REST stack, I scaled the
> OAuth/xAuth wall. In my view, everyone made this transition seem much
> tougher than it really is. Here's my advice:
>
> 0) If you don't have a REST stack, git one! There are many out there. I
> started with one. (Very little of it remains in my apps but that is another
> matter. It got me started.)
>
> 1) Your http request tends to change in exactly one place -- setting your
> authorization header. Don't freak out about changing your code base. I added
> 3 methods to my stack: create a signature string, sign the signature string
> and create the OAuth header. I changed one method to sort and URL encode my
> parameters. In all, this is a pretty minimal change. I cribbed much of this
> from other open source implementations.
>
> 1a) Calculating a signature string is not as daunting as it looks. Some
> pseudo code would have helped. Twitter's recent documentation helped.
> 1b) Calculating HMAC-SHA1 signature is simple too. If you use the common
> crypto library (CDSA derived), it takes 6 lines.
> 1c) What wasn't too clear was how the xAuth process interacted with your
> tokens. (Yes, I knew they were missing. What wasn't apparent was that I had
> to leave the conjoining '&' in the signature secret.)
>
> 2) The WWDC slides sum up most of the issues but leave out the supporting
> nitty gritty code.
>
>Finally, we all know that xAuth has a huge security hole -- the
> embedded consumer secret in the client app. I have a feature request into
> Apple to allow the passing of encrypted secrets to native applications
> through App Store binary code. I have also posted it to OpenRadar at this
> link: . If members of this community
> agree that we need a solution to this problem, then please consider filing
> enhancement requests with Apple via bugreporter and reference my request.
> (If someone else has a similar request, I'll be happy to reference their
> request in my communications with Apple.)
>
> Anon,
> Andrew
> 
> Andrew W. Donoho
> Donoho Design Group, L.L.C.
> a...@ddg.com, +1 (512) 750-7596
>
> "We did not come to fear the future.
>We came here to shape it."
>
> -- President Barack Obama, Sept. 2009
>
>
>
>
>
>

Re: [twitter-dev] Access Token

[Taylor Singletary]

For a desktop application you have one of two options -- use the PIN code
flow in which you still must send the user to a web browser to enter their
credentials, after which the user will be presented with a PIN code that
they must hand-enter into your application. Your other alternative is xAuth,
which allows your application to exchange a login and password for an OAuth
1.0a access token.

Sample code for these processes are very dependent on the language being
used. What language are you planning on developing in? If you're familiar
with PHP, there are many good code examples in Abraham's oauthtwitter
library: http://github.com/abraham/twitteroauth and the documentation
http://github.com/abraham/twitteroauth/blob/master/DOCUMENTATION

Taylor


On Sat, Jun 26, 2010 at 12:10 AM, manjunath reddy <
manjunathredd...@gmail.com> wrote:

> Hi taylor.
>   I am using java api to interact with twitter...Mine is an desktop
> application in which i cant the ask the user to enter the login credentials.
>   How can i  get the PIN in desktop applicationa.
>   Can u please provide me some sample code for the same.
>
> On Fri, Jun 25, 2010 at 2:32 AM, Taylor Singletary <
> taylorsinglet...@twitter.com> wrote:
>
>> Hi Manjunath,
>>
>> You'll want to read about implementing OAuth in your application at
>> http://dev.twitter.com/auth -- there are some convenient features we
>> offer to acquire an access token for your own account and own application,
>> but you'll still need to implement the bulk of OAuth.
>>
>> Taylor
>>
>>
>> On Wed, Jun 23, 2010 at 11:16 PM, manjunath reddy <
>> manjunathredd...@gmail.com> wrote:
>>
>>> HI
>>>  I have an requirement of reading all the  tweets that has specifed
>>> word and replying to that tweeet.
>>>
>>> I am able to query all the tweets while replying to the tweet i am
>>> getting error.Couldnt autheticate the user.
>>>
>>> Please let me know how can i get the access token for the user.
>>> Please help me in resolving this issue.
>>>
>>> Regards
>>> Manjunatha M.N
>>>
>>
>>
>
>
> --
> Climbing to the top demands strength, whether it is to the top of Mount
> Everest or to the top of your career.
>

Re: [twitter-dev] Re: 404 Problem 3 day

[Taylor Singletary]

Are you attaching anything else to the request? 400 bad request usually
implies that there was some kind of error in how the resource was being
accessed. Is there anything different about how you're requesting the home
timeline versus any other resource? Which library are you using?

Taylor

On Sat, Jun 26, 2010 at 2:42 AM, iLyas  wrote:

> " The remote server returned an error: (400) Bad Request "
>
> but other function is work mentions favorites list bla bla..
>
> only problem is hometimeline :S
>
>
> On Jun 25, 4:42 pm, Taylor Singletary 
> wrote:
> > And are you sure you're getting a 404 and not some other error code?
> >
> > On Fri, Jun 25, 2010 at 4:02 AM, iLyas 
> wrote:
> > > thank you Taylor
> >
> > > I'm use this "http://api.twitter.com/1/statuses/home_timeline.json";
>

[twitter-dev] Get username from Twitter API

[thomas]

Hi all,

I have created a Twitter app using oAuth for authentication.

However, I cannot find any info on how I can retrieve the user's
username in order to get his details. By user, I mean the one that
granted my app permission and for whom the app is making the API calls

Thank you

Re: [twitter-dev] Get username from Twitter API

[Taylor Singletary]

Hi Thomas,

There are a few ways you retrieve this information. When you are on the
final leg of your OAuth transaction (exchanging a request token for an
access token), part of the response that you get back includes the user id
and screen name for the authenticating user:

oauth_token=819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw&oauth_token_secret=J6zix3FfA9LofH0awS24M3HcBYXO5nI1iYe8EfBA&user_id=819797&screen_name=episod

(Notice both "screen_name" and "user_id" keys)

You can also make an OAuth authenticated call to
http://api.twitter.com/1/account/verify_credentials.xml and receive the
information you're looking for back in either XML or JSON format.

Taylor

On Mon, Jun 28, 2010 at 7:02 AM, thomas  wrote:

> Hi all,
>
> I have created a Twitter app using oAuth for authentication.
>
> However, I cannot find any info on how I can retrieve the user's
> username in order to get his details. By user, I mean the one that
> granted my app permission and for whom the app is making the API calls
>
> Thank you
>

Re: [twitter-dev] Re: Streaming API OAuth explanation?

[Taylor Singletary]

Wil: Can you retrieve the signature base string (again, from your current
work) from your library when attempting the call that returns 401? There
must be something minor going amiss there with this parameter for some
reason.

Thanks,
Taylor

On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki  wrote:

> An invalid delimited parameter is ignored, and won't cause a 401.
>
>
> On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
>
>> Hi,
>>
>> @John: I removed the delimited=1 parameter and it still gave me 401's.
>>
>> @Taylor: I checked my system clock and does not differ from the server
>> time by more than 5 minutes.
>> The code works with the following which I've used:
>> 1) OAuth authentication methods
>> 2) statuses/user_timeline
>> 3) 1/favorites/create
>>
>> (3) is a bit wierd since TweetSharp sends favorite requests in this
>> form:
>> http://api.twitter.com/1/favorites/create/##.json
>>
>> and the POST body contains this:
>> source=Wildfire%20by%20Implication
>>
>> Yet it still works. I haven't tried other things in TweetSharp that
>> does POST though.
>> I thought that it was probably the read/write permissions that's
>> causing the problem because I initially set the App as read-only (I
>> changed it to write-access when I implemented the favorite). I then
>> recreated the client information with read&write access. So I guess
>> permissions weren't the problem.
>>
>> I did some packet sniffing to be extra sure that it's sending the data
>> as POST... and I got this: (using Microsoft NetMon 3.3)
>> - Http: Request, POST /1/statuses/filter.json , Using OAuth
>> Authorization
>>Command: POST
>>  + URI: /1/statuses/filter.json
>>ProtocolVersion: HTTP/1.1
>>  - Authorization: OAuth
>>   - Authorization:  OAuth
>> oauth_consumer_key="##",oauth_token="34216267-
>>
>> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",oauth_timestamp="1277542341",oauth_signature_method="HMAC-
>> SHA1",oauth_signature="PeKBoS3uYgL9p7oJ%2
>>  WhiteSpace:
>>  AuthorizationData: OAuth
>> oauth_consumer_key="###",oauth_token="34216267-
>>
>> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",oauth_timestamp="1277542341",oauth_signature_method="HMAC-
>> SHA1",oauth_signature="PeKBoS3uYgL9p7o
>>  + ContentType:  application/x-www-form-urlencoded
>>Host:  stream.twitter.com
>>ContentLength:  51
>>Connection:  Keep-Alive
>>HeaderEnd: CRLF
>>
>>
>> The next frame was the HTTP payload
>> - Http: HTTP Payload, URL: /1/statuses/filter.json
>>  - payload: HttpContentType =  application/x-www-form-urlencoded
>> source: softwarename
>> follow: ###
>>
>> On Jun 26, 5:50 am, Taylor Singletary 
>> wrote:
>> > Wil,
>> >
>> > Does your OAuth code work against other aspects of the Twitter API? Can
>> you
>> > verify if your system's clock is within 5 minutes or so of the times
>> > returned by our system? (You can see the current server time in an HTTP
>> > header of any of our responses).
>> >
>> > Are you sure that your code is actually POSTing the POST body along with
>> the
>> > request?
>> >
>> > Seems like you are really close.
>> >
>> >
>> >
>> > On Fri, Jun 25, 2010 at 10:10 AM, Wil  wrote:
>> > > Hi John,
>> >
>> > > Uhh, care to elaborate? I don't quite get what you meant...
>> >
>> > > Thanks,
>> > > Wil
>> >
>> > > On Jun 24, 11:17 pm, John Kalucki  wrote:
>> > > > Aside from the oAuth issue, which others can address, the only valid
>> > > > delimited value is length.
>> >
>> > > > -John
>> >
>> > > > On Thu, Jun 24, 2010 at 7:58 AM, Wil  wrote:
>> > > > > I'm getting this response:
>> >
>> > > > > HTTP/1.1 401 Unauthorized
>> > > > > Content-Length: 1296
>> > > > > Cache-Control: must-revalidate,no-cache,no-store
>> > > > > Content-Type: text/html; charset=iso-8859-1
>> > > > > Server: Jetty(6.1.17)
>> > > > > WWW-Authenticate: Basic realm="Firehose"
>> >
>> > > > >  
>> > > > > 
>> > > > > 
>> > > > > Error 401 UNAUTHORIZED
>> > > > > 
>> > > > > 
>> > > > > HTTP ERROR: 401
>> > > > > Problem accessing /1/statuses/filter.json. Reason:
>> > > > > UNAUTHORIZED
>> > > > > Powered by Jetty://
>> >
>> > > > > Here's what I POSTed(oauth tokens are filtered out):
>> >
>> > > > > REQUEST: POSThttp://stream.twitter.com/1/statuses/filter.json
>> > > > > Authorization: OAuth
>> >
>> > >
>> oauth_consumer_key="#",oauth_token="",oauth_nonce="#",oauth
>> > > _timestamp="#",oauth_signature_method="HMAC-
>> > > > > SHA1",oauth_signature="",oauth_version="1.0",
>> > > > > Content-Type: application/x-www-form-urlencoded
>> > > > > Vary: Accept-Encoding
>> > > > > Connection: close
>> >
>> > > > > source=softwarename&delimited=1&follow=156934710
>> >
>> > > > > On Jun 23, 1:33 am, John Kalucki  wrote:
>> > > > > > OAuthshould work fine onstream.twitter.com
>> >
>> > > > > > -John Kaluckihttp://twitter.com/jkalucki
>> > > > > > Infrastructure, Twitter Inc.
>> >
>> > > > > > On Tue, Jun 22, 2010 at 10:00 AM, Wil 
>> wrote:
>> 

Re: [twitter-dev] incorrect signatures

[Taylor Singletary]

It may have corresponded with a spike of activity on Twitter -- our current
authentication implementation has some unfortunate side effects when
stressed, and one of them is to return spurious 401s.

Are you still seeing the issue?

On Sat, Jun 26, 2010 at 11:39 AM, Udi  wrote:

> we recently (24-48 hours ago) started getting "incorrect signature"
> errors for some of our users. accessing the twitter api with the same
> software and the same auth data from a different location works fine.
> for one user there were only issues with home_timeline.json but
> user_timeline.json worked fine.
>
> any ideas?
>
> thanks,
> udi
>

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

Hi Taylor,

Ok. Here's the entire thing:

Generated base string:
POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
%2Ffilter.json&follow%3D156934710%26oauth_consumer_key
%3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
%3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
%3DWildfire%2520by%2520Implication

calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D

Sniffed authorization header:
oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
oauth_nonce="6qzbdouhrz40dqs4"
oauth_timestamp="1277735291"
oauth_signature_method="HMAC-SHA1"
oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
oauth_version="1.0"

You're right, something seems to be wrong with the signature. I'll
continue to investigate this

Regards,
Wil
On Jun 28, 10:23 pm, Taylor Singletary 
wrote:
> Wil: Can you retrieve the signature base string (again, from your current
> work) from your library when attempting the call that returns 401? There
> must be something minor going amiss there with this parameter for some
> reason.
>
> Thanks,
> Taylor
>
>
>
> On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki  wrote:
> > An invalid delimited parameter is ignored, and won't cause a 401.
>
> > On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
>
> >> Hi,
>
> >> @John: I removed the delimited=1 parameter and it still gave me 401's.
>
> >> @Taylor: I checked my system clock and does not differ from the server
> >> time by more than 5 minutes.
> >> The code works with the following which I've used:
> >> 1) OAuth authentication methods
> >> 2) statuses/user_timeline
> >> 3) 1/favorites/create
>
> >> (3) is a bit wierd since TweetSharp sends favorite requests in this
> >> form:
> >>http://api.twitter.com/1/favorites/create/##.json
>
> >> and the POST body contains this:
> >> source=Wildfire%20by%20Implication
>
> >> Yet it still works. I haven't tried other things in TweetSharp that
> >> does POST though.
> >> I thought that it was probably the read/write permissions that's
> >> causing the problem because I initially set the App as read-only (I
> >> changed it to write-access when I implemented the favorite). I then
> >> recreated the client information with read&write access. So I guess
> >> permissions weren't the problem.
>
> >> I did some packet sniffing to be extra sure that it's sending the data
> >> as POST... and I got this: (using Microsoft NetMon 3.3)
> >> - Http: Request, POST /1/statuses/filter.json , Using OAuth
> >> Authorization
> >>    Command: POST
> >>  + URI: /1/statuses/filter.json
> >>    ProtocolVersion: HTTP/1.1
> >>  - Authorization: OAuth
> >>   - Authorization:  OAuth
> >> oauth_consumer_key="##",oauth_token="34216267-
>
> >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> >> SHA1",oauth_signature="PeKBoS3uYgL9p7oJ%2
> >>      WhiteSpace:
> >>      AuthorizationData: OAuth
> >> oauth_consumer_key="###",oauth_token="34216267-
>
> >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> >> SHA1",oauth_signature="PeKBoS3uYgL9p7o
> >>  + ContentType:  application/x-www-form-urlencoded
> >>    Host:  stream.twitter.com
> >>    ContentLength:  51
> >>    Connection:  Keep-Alive
> >>    HeaderEnd: CRLF
>
> >> The next frame was the HTTP payload
> >> - Http: HTTP Payload, URL: /1/statuses/filter.json
> >>  - payload: HttpContentType =  application/x-www-form-urlencoded
> >>     source: softwarename
> >>     follow: ###
>
> >> On Jun 26, 5:50 am, Taylor Singletary 
> >> wrote:
> >> > Wil,
>
> >> > Does your OAuth code work against other aspects of the Twitter API? Can
> >> you
> >> > verify if your system's clock is within 5 minutes or so of the times
> >> > returned by our system? (You can see the current server time in an HTTP
> >> > header of any of our responses).
>
> >> > Are you sure that your code is actually POSTing the POST body along with
> >> the
> >> > request?
>
> >> > Seems like you are really close.
>
> >> > On Fri, Jun 25, 2010 at 10:10 AM, Wil  wrote:
> >> > > Hi John,
>
> >> > > Uhh, care to elaborate? I don't quite get what you meant...
>
> >> > > Thanks,
> >> > > Wil
>
> >> > > On Jun 24, 11:17 pm, John Kalucki  wrote:
> >> > > > Aside from the oAuth issue, which others can address, the only valid
> >> > > > delimited value is length.
>
> >> > > > -John
>
> >> > > > On Thu, Jun 24, 2010 at 7:58 AM, Wil  wrote:
> >> > > > > I'm getting this response:
>
> >> > > > > HTTP/1.1 401 Unauthorized
> >> > > > > Content-Length: 1296
> >> > > > > Cache-Control: must-revalidate,no-cache,no-store
> >> > > > > Content-Type: text/html; charset=iso-8859-1
> >> > > > > Server: Jetty(6.1.17)
> >> > > > > WWW-Authenticate: Basic realm="Firehose"
>
> >> > > > >  
> >>

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

Ah wait, I ran a couple more tests just to be sure and the signatures
match the sent sniffed one guess I missed something previously...

Base:
POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
%2Ffilter.json&follow%3D156934710%26oauth_consumer_key
%3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
%3D1277736634%26oauth_token%3D156934710-
J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
%3DWildfire%2520by%2520Implication

Signature:
nt%2F5itdHGoVr8gRloaBOakSmUbM%3D

Sent:
oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
oauth_nonce="eodjuo8ystdcyl3f"
oauth_timestamp="1277736634"
oauth_signature_method="HMAC-SHA1"
oauth_signature="nt%2F5itdHGoVr8gRloaBOakSmUbM%3D"
oauth_version="1.0"


On Jun 28, 10:35 pm, Wil  wrote:
> Hi Taylor,
>
> Ok. Here's the entire thing:
>
> Generated base string:
> POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
> %3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
> SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
> J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> %3DWildfire%2520by%2520Implication
>
> calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D
>
> Sniffed authorization header:
> oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> oauth_nonce="6qzbdouhrz40dqs4"
> oauth_timestamp="1277735291"
> oauth_signature_method="HMAC-SHA1"
> oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
> oauth_version="1.0"
>
> You're right, something seems to be wrong with the signature. I'll
> continue to investigate this
>
> Regards,
> Wil
> On Jun 28, 10:23 pm, Taylor Singletary 
> wrote:
>
>
>
> > Wil: Can you retrieve the signature base string (again, from your current
> > work) from your library when attempting the call that returns 401? There
> > must be something minor going amiss there with this parameter for some
> > reason.
>
> > Thanks,
> > Taylor
>
> > On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki  wrote:
> > > An invalid delimited parameter is ignored, and won't cause a 401.
>
> > > On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
>
> > >> Hi,
>
> > >> @John: I removed the delimited=1 parameter and it still gave me 401's.
>
> > >> @Taylor: I checked my system clock and does not differ from the server
> > >> time by more than 5 minutes.
> > >> The code works with the following which I've used:
> > >> 1)OAuthauthentication methods
> > >> 2) statuses/user_timeline
> > >> 3) 1/favorites/create
>
> > >> (3) is a bit wierd since TweetSharp sends favorite requests in this
> > >> form:
> > >>http://api.twitter.com/1/favorites/create/##.json
>
> > >> and the POST body contains this:
> > >> source=Wildfire%20by%20Implication
>
> > >> Yet it still works. I haven't tried other things in TweetSharp that
> > >> does POST though.
> > >> I thought that it was probably the read/write permissions that's
> > >> causing the problem because I initially set the App as read-only (I
> > >> changed it to write-access when I implemented the favorite). I then
> > >> recreated the client information with read&write access. So I guess
> > >> permissions weren't the problem.
>
> > >> I did some packet sniffing to be extra sure that it's sending the data
> > >> as POST... and I got this: (using Microsoft NetMon 3.3)
> > >> - Http: Request, POST /1/statuses/filter.json , UsingOAuth
> > >> Authorization
> > >>    Command: POST
> > >>  + URI: /1/statuses/filter.json
> > >>    ProtocolVersion: HTTP/1.1
> > >>  - Authorization:OAuth
> > >>   - Authorization:  OAuth
> > >> oauth_consumer_key="##",oauth_token="34216267-
>
> > >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> > >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > >> SHA1",oauth_signature="PeKBoS3uYgL9p7oJ%2
> > >>      WhiteSpace:
> > >>      AuthorizationData:OAuth
> > >> oauth_consumer_key="###",oauth_token="34216267-
>
> > >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> > >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > >> SHA1",oauth_signature="PeKBoS3uYgL9p7o
> > >>  + ContentType:  application/x-www-form-urlencoded
> > >>    Host:  stream.twitter.com
> > >>    ContentLength:  51
> > >>    Connection:  Keep-Alive
> > >>    HeaderEnd: CRLF
>
> > >> The next frame was the HTTP payload
> > >> - Http: HTTP Payload, URL: /1/statuses/filter.json
> > >>  - payload: HttpContentType =  application/x-www-form-urlencoded
> > >>     source: softwarename
> > >>     follow: ###
>
> > >> On Jun 26, 5:50 am, Taylor Singletary 
> > >> wrote:
> > >> > Wil,
>
> > >> > Does yourOAuthcode work against other aspects of the Twitter API? Can
> > >> you
> > >> > verify if your system's clock is within 5 minutes o

[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API

[Decklin Foster]

Taylor Singletary wrote:
> We're waiting on a few minor bug fixes to be in place before rolling this
> out to a wider audience. I'll post a new message when things are good to go
> and we're ready to accept applications into the feature.

Any update or ETA on this? I have an app that I'm eager to test out.
(I notice that if you open http://dev.twitter.com/apps/key_exchange
with a valid oauth_consumer_key, instead of a 404 there is a page that
says "Sorry, key exchange is not permitted for this application." Does
this mean the answer is "soon"?)

-- 
things change.
deck...@red-bean.com

Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API

[Taylor Singletary]

The answer is soon! :) We hope to roll this out more widely this week.

On Mon, Jun 28, 2010 at 7:56 AM, Decklin Foster wrote:

> Taylor Singletary wrote:
> > We're waiting on a few minor bug fixes to be in place before rolling this
> > out to a wider audience. I'll post a new message when things are good to
> go
> > and we're ready to accept applications into the feature.
>
> Any update or ETA on this? I have an app that I'm eager to test out.
> (I notice that if you open http://dev.twitter.com/apps/key_exchange
> with a valid oauth_consumer_key, instead of a 404 there is a page that
> says "Sorry, key exchange is not permitted for this application." Does
> this mean the answer is "soon"?)
>
> --
> things change.
> deck...@red-bean.com
>

[twitter-dev] Search?

[Mack D. Male]

What's the deal with search? It's not returning all the data. Just
look at any of the trending topics for instance. The Status site
hasn't been updated.

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

The thing wasn't including the POST parameters in the signing! I think
I got it!

On Jun 28, 10:54 pm, Wil  wrote:
> Ah wait, I ran a couple more tests just to be sure and the signatures
> match the sent sniffed one guess I missed something previously...
>
> Base:
> POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
> %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
> %3D1277736634%26oauth_token%3D156934710-
> J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> %3DWildfire%2520by%2520Implication
>
> Signature:
> nt%2F5itdHGoVr8gRloaBOakSmUbM%3D
>
> Sent:
> oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> oauth_nonce="eodjuo8ystdcyl3f"
> oauth_timestamp="1277736634"
> oauth_signature_method="HMAC-SHA1"
> oauth_signature="nt%2F5itdHGoVr8gRloaBOakSmUbM%3D"
> oauth_version="1.0"
>
> On Jun 28, 10:35 pm, Wil  wrote:
>
>
>
> > Hi Taylor,
>
> > Ok. Here's the entire thing:
>
> > Generated base string:
> > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
> > %3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
> > SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
> > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > %3DWildfire%2520by%2520Implication
>
> > calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D
>
> > Sniffed authorization header:
> > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > oauth_nonce="6qzbdouhrz40dqs4"
> > oauth_timestamp="1277735291"
> > oauth_signature_method="HMAC-SHA1"
> > oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
> > oauth_version="1.0"
>
> > You're right, something seems to be wrong with the signature. I'll
> > continue to investigate this
>
> > Regards,
> > Wil
> > On Jun 28, 10:23 pm, Taylor Singletary 
> > wrote:
>
> > > Wil: Can you retrieve the signature base string (again, from your current
> > > work) from your library when attempting the call that returns 401? There
> > > must be something minor going amiss there with this parameter for some
> > > reason.
>
> > > Thanks,
> > > Taylor
>
> > > On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki  wrote:
> > > > An invalid delimited parameter is ignored, and won't cause a 401.
>
> > > > On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
>
> > > >> Hi,
>
> > > >> @John: I removed the delimited=1 parameter and it still gave me 401's.
>
> > > >> @Taylor: I checked my system clock and does not differ from the server
> > > >> time by more than 5 minutes.
> > > >> The code works with the following which I've used:
> > > >> 1)OAuthauthentication methods
> > > >> 2) statuses/user_timeline
> > > >> 3) 1/favorites/create
>
> > > >> (3) is a bit wierd since TweetSharp sends favorite requests in this
> > > >> form:
> > > >>http://api.twitter.com/1/favorites/create/##.json
>
> > > >> and the POST body contains this:
> > > >> source=Wildfire%20by%20Implication
>
> > > >> Yet it still works. I haven't tried other things in TweetSharp that
> > > >> does POST though.
> > > >> I thought that it was probably the read/write permissions that's
> > > >> causing the problem because I initially set the App as read-only (I
> > > >> changed it to write-access when I implemented the favorite). I then
> > > >> recreated the client information with read&write access. So I guess
> > > >> permissions weren't the problem.
>
> > > >> I did some packet sniffing to be extra sure that it's sending the data
> > > >> as POST... and I got this: (using Microsoft NetMon 3.3)
> > > >> - Http: Request, POST /1/statuses/filter.json , UsingOAuth
> > > >> Authorization
> > > >>    Command: POST
> > > >>  + URI: /1/statuses/filter.json
> > > >>    ProtocolVersion: HTTP/1.1
> > > >>  - Authorization:OAuth
> > > >>   - Authorization:  OAuth
> > > >> oauth_consumer_key="##",oauth_token="34216267-
>
> > > >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> > > >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > > >> SHA1",oauth_signature="PeKBoS3uYgL9p7oJ%2
> > > >>      WhiteSpace:
> > > >>      AuthorizationData:OAuth
> > > >> oauth_consumer_key="###",oauth_token="34216267-
>
> > > >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> > > >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > > >> SHA1",oauth_signature="PeKBoS3uYgL9p7o
> > > >>  + ContentType:  application/x-www-form-urlencoded
> > > >>    Host:  stream.twitter.com
> > > >>    ContentLength:  51
> > > >>    Connection:  Keep-Alive
> > > >>    HeaderEnd: CRLF
>
> > > >> The next frame was the HTTP payload
> > > >> - Http: HTTP Payload, URL: /1/statuses/filter.json
> > > >>  - payload: HttpContentType =  a

Re: [twitter-dev] Re: Streaming API OAuth explanation?

[Taylor Singletary]

Great! Let me know if you still need assistance.

Taylor

On Mon, Jun 28, 2010 at 8:10 AM, Wil  wrote:

> The thing wasn't including the POST parameters in the signing! I think
> I got it!
>
> On Jun 28, 10:54 pm, Wil  wrote:
> > Ah wait, I ran a couple more tests just to be sure and the signatures
> > match the sent sniffed one guess I missed something previously...
> >
> > Base:
> > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
> > %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
> > %3D1277736634%26oauth_token%3D156934710-
> > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > %3DWildfire%2520by%2520Implication
> >
> > Signature:
> > nt%2F5itdHGoVr8gRloaBOakSmUbM%3D
> >
> > Sent:
> > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > oauth_nonce="eodjuo8ystdcyl3f"
> > oauth_timestamp="1277736634"
> > oauth_signature_method="HMAC-SHA1"
> > oauth_signature="nt%2F5itdHGoVr8gRloaBOakSmUbM%3D"
> > oauth_version="1.0"
> >
> > On Jun 28, 10:35 pm, Wil  wrote:
> >
> >
> >
> > > Hi Taylor,
> >
> > > Ok. Here's the entire thing:
> >
> > > Generated base string:
> > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
> > > %3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
> > > SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
> > > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > %3DWildfire%2520by%2520Implication
> >
> > > calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D
> >
> > > Sniffed authorization header:
> > > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > > oauth_nonce="6qzbdouhrz40dqs4"
> > > oauth_timestamp="1277735291"
> > > oauth_signature_method="HMAC-SHA1"
> > > oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
> > > oauth_version="1.0"
> >
> > > You're right, something seems to be wrong with the signature. I'll
> > > continue to investigate this
> >
> > > Regards,
> > > Wil
> > > On Jun 28, 10:23 pm, Taylor Singletary 
> > > wrote:
> >
> > > > Wil: Can you retrieve the signature base string (again, from your
> current
> > > > work) from your library when attempting the call that returns 401?
> There
> > > > must be something minor going amiss there with this parameter for
> some
> > > > reason.
> >
> > > > Thanks,
> > > > Taylor
> >
> > > > On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki 
> wrote:
> > > > > An invalid delimited parameter is ignored, and won't cause a 401.
> >
> > > > > On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
> >
> > > > >> Hi,
> >
> > > > >> @John: I removed the delimited=1 parameter and it still gave me
> 401's.
> >
> > > > >> @Taylor: I checked my system clock and does not differ from the
> server
> > > > >> time by more than 5 minutes.
> > > > >> The code works with the following which I've used:
> > > > >> 1)OAuthauthentication methods
> > > > >> 2) statuses/user_timeline
> > > > >> 3) 1/favorites/create
> >
> > > > >> (3) is a bit wierd since TweetSharp sends favorite requests in
> this
> > > > >> form:
> > > > >>http://api.twitter.com/1/favorites/create/##.json
> >
> > > > >> and the POST body contains this:
> > > > >> source=Wildfire%20by%20Implication
> >
> > > > >> Yet it still works. I haven't tried other things in TweetSharp
> that
> > > > >> does POST though.
> > > > >> I thought that it was probably the read/write permissions that's
> > > > >> causing the problem because I initially set the App as read-only
> (I
> > > > >> changed it to write-access when I implemented the favorite). I
> then
> > > > >> recreated the client information with read&write access. So I
> guess
> > > > >> permissions weren't the problem.
> >
> > > > >> I did some packet sniffing to be extra sure that it's sending the
> data
> > > > >> as POST... and I got this: (using Microsoft NetMon 3.3)
> > > > >> - Http: Request, POST /1/statuses/filter.json , UsingOAuth
> > > > >> Authorization
> > > > >>Command: POST
> > > > >>  + URI: /1/statuses/filter.json
> > > > >>ProtocolVersion: HTTP/1.1
> > > > >>  - Authorization:OAuth
> > > > >>   - Authorization:  OAuth
> > > > >> oauth_consumer_key="##",oauth_token="34216267-
> >
> > > > >>
> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > > > >> SHA1",oauth_signature="PeKBoS3uYgL9p7oJ%2
> > > > >>  WhiteSpace:
> > > > >>  AuthorizationData:OAuth
> > > > >> oauth_consumer_key="###",oauth_token="34216267-
> >
> > > > >>
> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > > > >> SHA1",oauth_signature

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

Oh wait, it does include them I just missed it.

So much for premature celebration...

On Jun 28, 11:10 pm, Wil  wrote:
> The thing wasn't including the POST parameters in the signing! I think
> I got it!
>
> On Jun 28, 10:54 pm, Wil  wrote:
>
>
>
> > Ah wait, I ran a couple more tests just to be sure and the signatures
> > match the sent sniffed one guess I missed something previously...
>
> > Base:
> > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
> > %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
> > %3D1277736634%26oauth_token%3D156934710-
> > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > %3DWildfire%2520by%2520Implication
>
> > Signature:
> > nt%2F5itdHGoVr8gRloaBOakSmUbM%3D
>
> > Sent:
> > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > oauth_nonce="eodjuo8ystdcyl3f"
> > oauth_timestamp="1277736634"
> > oauth_signature_method="HMAC-SHA1"
> > oauth_signature="nt%2F5itdHGoVr8gRloaBOakSmUbM%3D"
> > oauth_version="1.0"
>
> > On Jun 28, 10:35 pm, Wil  wrote:
>
> > > Hi Taylor,
>
> > > Ok. Here's the entire thing:
>
> > > Generated base string:
> > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
> > > %3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
> > > SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
> > > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > %3DWildfire%2520by%2520Implication
>
> > > calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D
>
> > > Sniffed authorization header:
> > > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > > oauth_nonce="6qzbdouhrz40dqs4"
> > > oauth_timestamp="1277735291"
> > > oauth_signature_method="HMAC-SHA1"
> > > oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
> > > oauth_version="1.0"
>
> > > You're right, something seems to be wrong with the signature. I'll
> > > continue to investigate this
>
> > > Regards,
> > > Wil
> > > On Jun 28, 10:23 pm, Taylor Singletary 
> > > wrote:
>
> > > > Wil: Can you retrieve the signature base string (again, from your 
> > > > current
> > > > work) from your library when attempting the call that returns 401? There
> > > > must be something minor going amiss there with this parameter for some
> > > > reason.
>
> > > > Thanks,
> > > > Taylor
>
> > > > On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki  wrote:
> > > > > An invalid delimited parameter is ignored, and won't cause a 401.
>
> > > > > On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
>
> > > > >> Hi,
>
> > > > >> @John: I removed the delimited=1 parameter and it still gave me 
> > > > >> 401's.
>
> > > > >> @Taylor: I checked my system clock and does not differ from the 
> > > > >> server
> > > > >> time by more than 5 minutes.
> > > > >> The code works with the following which I've used:
> > > > >> 1)OAuthauthentication methods
> > > > >> 2) statuses/user_timeline
> > > > >> 3) 1/favorites/create
>
> > > > >> (3) is a bit wierd since TweetSharp sends favorite requests in this
> > > > >> form:
> > > > >>http://api.twitter.com/1/favorites/create/##.json
>
> > > > >> and the POST body contains this:
> > > > >> source=Wildfire%20by%20Implication
>
> > > > >> Yet it still works. I haven't tried other things in TweetSharp that
> > > > >> does POST though.
> > > > >> I thought that it was probably the read/write permissions that's
> > > > >> causing the problem because I initially set the App as read-only (I
> > > > >> changed it to write-access when I implemented the favorite). I then
> > > > >> recreated the client information with read&write access. So I guess
> > > > >> permissions weren't the problem.
>
> > > > >> I did some packet sniffing to be extra sure that it's sending the 
> > > > >> data
> > > > >> as POST... and I got this: (using Microsoft NetMon 3.3)
> > > > >> - Http: Request, POST /1/statuses/filter.json , UsingOAuth
> > > > >> Authorization
> > > > >>    Command: POST
> > > > >>  + URI: /1/statuses/filter.json
> > > > >>    ProtocolVersion: HTTP/1.1
> > > > >>  - Authorization:OAuth
> > > > >>   - Authorization:  OAuth
> > > > >> oauth_consumer_key="##",oauth_token="34216267-
>
> > > > >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> > > > >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > > > >> SHA1",oauth_signature="PeKBoS3uYgL9p7oJ%2
> > > > >>      WhiteSpace:
> > > > >>      AuthorizationData:OAuth
> > > > >> oauth_consumer_key="###",oauth_token="34216267-
>
> > > > >> BDNO9E9Ayd3IDnzRsDgU0wwwcuxO3trNecmblpNQo",oauth_nonce="d8qtvqz2sefipbsu",o
> > > > >>  auth_timestamp="1277542341",oauth_signature_method="HMAC-
> > > > >> SHA1",oauth_signat

Re: [twitter-dev] Re: Streaming API OAuth explanation?

[Taylor Singletary]

Let's start from a common point. By using the same inputs, we can try and
meet in the middle with exactly the same signature, signature base string,
and authorization header.

Using the following values:
Consumer Key: TwitterConsumerKey
Consumer Secret: TwitterConsumerSecret
Access Token: TwitterAccessToken
Access Token Secret: TwitterAccessTokenScret
OAuth Nonce: abcdefgh
OAuth Timestamp: 1277739588

URL:
http://stream.twitter.com/1/statuses/filter.json

POST Body:
follow=156934710&source=Wildfire%20by%20Implication

Assuming these exact values, the following should be the result:

POST body:
follow=156934710&source=Wildfire%20by%20Implication

Signature Base String:
POST&http%3A%2F%2Fstream.twitter.com
%2F1%2Fstatuses%2Ffilter.json&follow%3D156934710%26oauth_consumer_key%3DTwitterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1277739588%26oauth_token%3DTwitterAccessToken%26oauth_version%3D1.0%26source%3DWildfire%2520by%2520Implication

Signing Secret
TwitterConsumerSecret&TwitterAccessTokenSecret

Signature
rYGiA6H2UXog0nYOzTeUKwJSssM=

Authorization Header
OAuth oauth_nonce="abcdefgh", oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1277739588", oauth_consumer_key="TwitterConsumerKey",
oauth_token="TwitterAccessToken",
oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM%3D", oauth_version="1.0"

Using these values do you get the same signature and other values?

Taylor

On Mon, Jun 28, 2010 at 8:21 AM, Wil  wrote:

> Oh wait, it does include them I just missed it.
>
> So much for premature celebration...
>
> On Jun 28, 11:10 pm, Wil  wrote:
> > The thing wasn't including the POST parameters in the signing! I think
> > I got it!
> >
> > On Jun 28, 10:54 pm, Wil  wrote:
> >
> >
> >
> > > Ah wait, I ran a couple more tests just to be sure and the signatures
> > > match the sent sniffed one guess I missed something previously...
> >
> > > Base:
> > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
> > > %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
> > > %3D1277736634%26oauth_token%3D156934710-
> > > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > %3DWildfire%2520by%2520Implication
> >
> > > Signature:
> > > nt%2F5itdHGoVr8gRloaBOakSmUbM%3D
> >
> > > Sent:
> > > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > > oauth_nonce="eodjuo8ystdcyl3f"
> > > oauth_timestamp="1277736634"
> > > oauth_signature_method="HMAC-SHA1"
> > > oauth_signature="nt%2F5itdHGoVr8gRloaBOakSmUbM%3D"
> > > oauth_version="1.0"
> >
> > > On Jun 28, 10:35 pm, Wil  wrote:
> >
> > > > Hi Taylor,
> >
> > > > Ok. Here's the entire thing:
> >
> > > > Generated base string:
> > > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
> > > > %3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
> > > > SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
> > > >
> J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > > %3DWildfire%2520by%2520Implication
> >
> > > > calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D
> >
> > > > Sniffed authorization header:
> > > > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > > > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > > > oauth_nonce="6qzbdouhrz40dqs4"
> > > > oauth_timestamp="1277735291"
> > > > oauth_signature_method="HMAC-SHA1"
> > > > oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
> > > > oauth_version="1.0"
> >
> > > > You're right, something seems to be wrong with the signature. I'll
> > > > continue to investigate this
> >
> > > > Regards,
> > > > Wil
> > > > On Jun 28, 10:23 pm, Taylor Singletary  >
> > > > wrote:
> >
> > > > > Wil: Can you retrieve the signature base string (again, from your
> current
> > > > > work) from your library when attempting the call that returns 401?
> There
> > > > > must be something minor going amiss there with this parameter for
> some
> > > > > reason.
> >
> > > > > Thanks,
> > > > > Taylor
> >
> > > > > On Sat, Jun 26, 2010 at 12:08 PM, John Kalucki 
> wrote:
> > > > > > An invalid delimited parameter is ignored, and won't cause a 401.
> >
> > > > > > On Sat, Jun 26, 2010 at 2:04 AM, Wil  wrote:
> >
> > > > > >> Hi,
> >
> > > > > >> @John: I removed the delimited=1 parameter and it still gave me
> 401's.
> >
> > > > > >> @Taylor: I checked my system clock and does not differ from the
> server
> > > > > >> time by more than 5 minutes.
> > > > > >> The code works with the following which I've used:
> > > > > >> 1)OAuthauthentication methods
> > > > > >> 2) statuses/user_timeline
> > > > > >> 3) 1/favorites/create
> >
> > > > > >> (3) is a bit wierd since TweetSharp sends favorite requests in
> this
> > > > > >> 

Re: [twitter-dev] Search?

[Jonathan Reichhold]

Can you provide more details?  We aren't seeing this behaviour.  Search has
never returned all of the data and in periods of high volume will not index
every single tweet.  If you want every tweet on a topic we highly suggest
the streaming interface.

Jonathan
@jreichhold

On Mon, Jun 28, 2010 at 8:09 AM, Mack D. Male  wrote:

> What's the deal with search? It's not returning all the data. Just
> look at any of the trending topics for instance. The Status site
> hasn't been updated.

[twitter-dev] Re: Get username from Twitter API

[thomas]

Excellent Taylor

Thanks a lot

I was going crazy with this

On 28 Ιούν, 17:19, Taylor Singletary 
wrote:
> Hi Thomas,
>
> There are a few ways you retrieve this information. When you are on the
> final leg of your OAuth transaction (exchanging a request token for an
> access token), part of the response that you get back includes the user id
> and screen name for the authenticating user:
>
> oauth_token=819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw&oauth_token_s­ecret=J6zix3FfA9LofH0awS24M3HcBYXO5nI1iYe8EfBA&user_id=819797&screen_name=e­pisod
>
> (Notice both "screen_name" and "user_id" keys)
>
> You can also make an OAuth authenticated call 
> tohttp://api.twitter.com/1/account/verify_credentials.xmland receive the
> information you're looking for back in either XML or JSON format.
>
> Taylor
>
>
>
> On Mon, Jun 28, 2010 at 7:02 AM, thomas  wrote:
> > Hi all,
>
> > I have created a Twitter app using oAuth for authentication.
>
> > However, I cannot find any info on how I can retrieve the user's
> > username in order to get his details. By user, I mean the one that
> > granted my app permission and for whom the app is making the API calls
>
> > Thank you

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

Hi,

I got exactly the same values:

Base string:
POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
%2Ffilter.json&follow%3D156934710%26oauth_consumer_key
%3DTwitterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method
%3DHMAC-SHA1%26oauth_timestamp%3D1277739588%26oauth_token
%3DTwitterAccessToken%26oauth_version%3D1.0%26source%3DWildfire%2520by
%2520Implication

Signature (escaped):
rYGiA6H2UXog0nYOzTeUKwJSssM%3D

Authorization Header:
oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oauth_nonce="abcdefgh",oauth_timestamp="1277739588",oauth_signature_method="HMAC-
SHA1",oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM
%3D",oauth_version="1.0"

Post content:
source=Wildfire%20by%20Implication&follow=156934710


On Jun 28, 11:45 pm, Taylor Singletary 
wrote:
> Let's start from a common point. By using the same inputs, we can try and
> meet in the middle with exactly the same signature, signature base string,
> and authorization header.
>
> Using the following values:
> Consumer Key: TwitterConsumerKey
> Consumer Secret: TwitterConsumerSecret
> Access Token: TwitterAccessToken
> Access Token Secret: TwitterAccessTokenScret
> OAuth Nonce: abcdefgh
> OAuth Timestamp: 1277739588
>
> URL:http://stream.twitter.com/1/statuses/filter.json
>
> POST Body:
> follow=156934710&source=Wildfire%20by%20Implication
>
> Assuming these exact values, the following should be the result:
>
> POST body:
> follow=156934710&source=Wildfire%20by%20Implication
>
> Signature Base String:
> POST&http%3A%2F%2Fstream.twitter.com
> %2F1%2Fstatuses%2Ffilter.json&follow%3D156934710%26oauth_consumer_key%3DTwi 
> tterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method%3DHMAC-SH 
> A1%26oauth_timestamp%3D1277739588%26oauth_token%3DTwitterAccessToken%26oaut 
> h_version%3D1.0%26source%3DWildfire%2520by%2520Implication
>
> Signing Secret
> TwitterConsumerSecret&TwitterAccessTokenSecret
>
> Signature
> rYGiA6H2UXog0nYOzTeUKwJSssM=
>
> Authorization Header
> OAuth oauth_nonce="abcdefgh", oauth_signature_method="HMAC-SHA1",
> oauth_timestamp="1277739588", oauth_consumer_key="TwitterConsumerKey",
> oauth_token="TwitterAccessToken",
> oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM%3D", oauth_version="1.0"
>
> Using these values do you get the same signature and other values?
>
> Taylor
>
>
>
> On Mon, Jun 28, 2010 at 8:21 AM, Wil  wrote:
> > Oh wait, it does include them I just missed it.
>
> > So much for premature celebration...
>
> > On Jun 28, 11:10 pm, Wil  wrote:
> > > The thing wasn't including the POST parameters in the signing! I think
> > > I got it!
>
> > > On Jun 28, 10:54 pm, Wil  wrote:
>
> > > > Ah wait, I ran a couple more tests just to be sure and the signatures
> > > > match the sent sniffed one guess I missed something previously...
>
> > > > Base:
> > > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
> > > > %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
> > > > %3D1277736634%26oauth_token%3D156934710-
> > > > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > > %3DWildfire%2520by%2520Implication
>
> > > > Signature:
> > > > nt%2F5itdHGoVr8gRloaBOakSmUbM%3D
>
> > > > Sent:
> > > > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > > > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > > > oauth_nonce="eodjuo8ystdcyl3f"
> > > > oauth_timestamp="1277736634"
> > > > oauth_signature_method="HMAC-SHA1"
> > > > oauth_signature="nt%2F5itdHGoVr8gRloaBOakSmUbM%3D"
> > > > oauth_version="1.0"
>
> > > > On Jun 28, 10:35 pm, Wil  wrote:
>
> > > > > Hi Taylor,
>
> > > > > Ok. Here's the entire thing:
>
> > > > > Generated base string:
> > > > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce
> > > > > %3Dmvzi5szav5dciif4%26oauth_signature_method%3DHMAC-
> > > > > SHA1%26oauth_timestamp%3D1277735188%26oauth_token%3D156934710-
>
> > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > > > %3DWildfire%2520by%2520Implication
>
> > > > > calculated signature: %2FgqbnKcwmnpFMGnqNUK3kr6waI0%3D
>
> > > > > Sniffed authorization header:
> > > > > oauth_consumer_key="rHYIlqotmSfiGc6OfFtw"
> > > > > oauth_token="156934710-J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E"
> > > > > oauth_nonce="6qzbdouhrz40dqs4"
> > > > > oauth_timestamp="1277735291"
> > > > > oauth_signature_method="HMAC-SHA1"
> > > > > oauth_signature="2yRkYN7j8YpS0%2FgrFSNKnoCrk7Y%3D"
> > > > > oauth_version="1.0"
>
> > > > > You're right, something seems to be wrong with the signature. I'll
> > > > > continue to investigate this
>
> > > > > Regards,
> > > > > Wil
> > > > > On Jun 28, 10:23 pm, Taylor Singletary 
> > > > > wrote:
>
> > > > > > Wil: Can you retrieve the signature base string (again, from your
> > current
> > > > >

Re: [twitter-dev] Re: Get username from Twitter API

[Emerson Damasceno]

Hello there,
I'm speaking on behalf of a third-party Brazilian site that wishes to use
OAuth, I ask you these following questions:
1. The site is a "Get more Followers" kind. In the past had been some issues
using OAuth, so the site discontinued that.
2. Is there any problem for this kind of service after the Change to OAuth,
on June 30th?
3. If so, what exactly would be necessary to avoid those reported issues?

I remain waiting for your answer.
Thanks a lot.
Kind yours,

Emerson Damasceno
twitter.com/emersonanomia

2010/6/28 thomas 

> Excellent Taylor
>
> Thanks a lot
>
> I was going crazy with this
>
> On 28 Ιούν, 17:19, Taylor Singletary 
> wrote:
> > Hi Thomas,
> >
> > There are a few ways you retrieve this information. When you are on the
> > final leg of your OAuth transaction (exchanging a request token for an
> > access token), part of the response that you get back includes the user
> id
> > and screen name for the authenticating user:
> >
> >
> oauth_token=819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw&oauth_token_s­ecret=J6zix3FfA9LofH0awS24M3HcBYXO5nI1iYe8EfBA&user_id=819797&screen_name=e­pisod
> >
> > (Notice both "screen_name" and "user_id" keys)
> >
> > You can also make an OAuth authenticated call tohttp://
> api.twitter.com/1/account/verify_credentials.xmland receive the
> > information you're looking for back in either XML or JSON format.
> >
> > Taylor
> >
> >
> >
> > On Mon, Jun 28, 2010 at 7:02 AM, thomas  wrote:
> > > Hi all,
> >
> > > I have created a Twitter app using oAuth for authentication.
> >
> > > However, I cannot find any info on how I can retrieve the user's
> > > username in order to get his details. By user, I mean the one that
> > > granted my app permission and for whom the app is making the API calls
> >
> > > Thank you




-- 
Emerson Damasceno
www.twitter.com/emersonanomia
www.facebook.com/emersondamasceno

[twitter-dev] Re: Search?

[Mack D. Male]

It looks like it is working again now. My test was as follows:

1) Go to http://search.twitter.com, click on the top trending topic.
2) Look at the 15 results returned. Usually they all say "half a
minute ago" or "less than a minute ago"

In my test, it said "3 minutes ago, 5 minutes ago, 9 minutes ago,
etc."

Thanks.

On Jun 28, 9:54 am, Jonathan Reichhold 
wrote:
> Can you provide more details?  We aren't seeing this behaviour.  Search has
> never returned all of the data and in periods of high volume will not index
> every single tweet.  If you want every tweet on a topic we highly suggest
> the streaming interface.
>
> Jonathan
> @jreichhold
>
> On Mon, Jun 28, 2010 at 8:09 AM, Mack D. Male  wrote:
>
>
>
> > What's the deal with search? It's not returning all the data. Just
> > look at any of the trending topics for instance. The Status site
> > hasn't been updated.

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

Hi again,

I made a "real" request this time because in the previous one, I
couldn't control the nonce and timestamp generation directly so I copy-
pasted the code it used and modified it a bit. This is the "real"
generated data which has a non-mock nonce and timestamp.

Timestamp: "1277742686"
Nonce: "ufywbndxv0qevuh0"

Base String:

POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
%2Ffilter.json&follow%3D156934710%26oauth_consumer_key
%3DTwitterConsumerKey%26oauth_nonce
%3Dufywbndxv0qevuh0%26oauth_signature_method%3DHMAC-
SHA1%26oauth_timestamp%3D1277742686%26oauth_token%3DTwitterAccessToken
%26oauth_version%3D1.0%26source%3DWildfire%2520by%2520Implication

Signature:
YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D

Packet Capture:
- Http: Request, POST /1/statuses/filter.json , Using OAuth
Authorization
Command: POST
  + URI: /1/statuses/filter.json
ProtocolVersion: HTTP/1.1
  - Authorization: OAuth
   + Authorization:  OAuth
oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oauth_nonce="ufywbndxv0qevuh0",oauth_timestamp="1277742686",oauth_signature_method="HMAC-
SHA1",oauth_signature="YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D",oauth_version="1.0",
  + ContentType:  application/x-www-form-urlencoded
Host:  stream.twitter.com
ContentLength:  51

- Http: HTTP Payload, URL: /1/statuses/filter.json
  - payload: HttpContentType =  application/x-www-form-urlencoded
 source: Wildfire%20by%20Implication
 follow: 156934710


It still looks correct though...

Regards,
Wil

On Jun 29, 12:21 am, Wil  wrote:
> Hi,
>
> I got exactly the same values:
>
> Base string:
> POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> %3DTwitterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method
> %3DHMAC-SHA1%26oauth_timestamp%3D1277739588%26oauth_token
> %3DTwitterAccessToken%26oauth_version%3D1.0%26source%3DWildfire%2520by
> %2520Implication
>
> Signature (escaped):
> rYGiA6H2UXog0nYOzTeUKwJSssM%3D
>
> Authorization Header:
> oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oa 
> uth_nonce="abcdefgh",oauth_timestamp="1277739588",oauth_signature_method="H 
> MAC-
> SHA1",oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM
> %3D",oauth_version="1.0"
>
> Post content:
> source=Wildfire%20by%20Implication&follow=156934710
>
> On Jun 28, 11:45 pm, Taylor Singletary 
> wrote:
>
>
>
> > Let's start from a common point. By using the same inputs, we can try and
> > meet in the middle with exactly the same signature, signature base string,
> > and authorization header.
>
> > Using the following values:
> > Consumer Key: TwitterConsumerKey
> > Consumer Secret: TwitterConsumerSecret
> > Access Token: TwitterAccessToken
> > Access Token Secret: TwitterAccessTokenScret
> > OAuth Nonce: abcdefgh
> > OAuth Timestamp: 1277739588
>
> > URL:http://stream.twitter.com/1/statuses/filter.json
>
> > POST Body:
> > follow=156934710&source=Wildfire%20by%20Implication
>
> > Assuming these exact values, the following should be the result:
>
> > POST body:
> > follow=156934710&source=Wildfire%20by%20Implication
>
> > Signature Base String:
> > POST&http%3A%2F%2Fstream.twitter.com
> > %2F1%2Fstatuses%2Ffilter.json&follow%3D156934710%26oauth_consumer_key%3DTwi 
> > tterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method%3DHMAC-SH 
> > A1%26oauth_timestamp%3D1277739588%26oauth_token%3DTwitterAccessToken%26oaut 
> > h_version%3D1.0%26source%3DWildfire%2520by%2520Implication
>
> > Signing Secret
> > TwitterConsumerSecret&TwitterAccessTokenSecret
>
> > Signature
> > rYGiA6H2UXog0nYOzTeUKwJSssM=
>
> > Authorization Header
> > OAuth oauth_nonce="abcdefgh", oauth_signature_method="HMAC-SHA1",
> > oauth_timestamp="1277739588", oauth_consumer_key="TwitterConsumerKey",
> > oauth_token="TwitterAccessToken",
> > oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM%3D", oauth_version="1.0"
>
> > Using these values do you get the same signature and other values?
>
> > Taylor
>
> > On Mon, Jun 28, 2010 at 8:21 AM, Wil  wrote:
> > > Oh wait, it does include them I just missed it.
>
> > > So much for premature celebration...
>
> > > On Jun 28, 11:10 pm, Wil  wrote:
> > > > The thing wasn't including the POST parameters in the signing! I think
> > > > I got it!
>
> > > > On Jun 28, 10:54 pm, Wil  wrote:
>
> > > > > Ah wait, I ran a couple more tests just to be sure and the signatures
> > > > > match the sent sniffed one guess I missed something previously...
>
> > > > > Base:
> > > > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > > > %3DrHYIlqotmSfiGc6OfFtw%26oauth_nonce%3Deodjuo8ystdcyl3f
> > > > > %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
> > > > > %3D1277736634%26oauth_token%3D156934710-
> > > > > J4HkTzZOaHk7ZBnXPzmqopoQS9pm2NjDJmMDEw4E%26oauth_version%3D1.0%26source
> > > > > %3DWildfire%2520by%2520Implication
>
> > > > > Signature:
> > > > > nt%2F5itdHGoVr8gRloaBOakSmUb

Re: [twitter-dev] Re: Streaming API OAuth explanation?

[Taylor Singletary]

Hi Wil,

Did some more tests. Why are you passing source in this context? I don't
recall this being an operator for the Streaming API. If you're passing it as
some kind of analogue to a source parameter you'd pass in basic auth on
tweet creation, it's unnecessary here unless there's some other use for it
that I'm unaware of. Without the source parameter, I'm able to make this
call work.

Taylor

On Mon, Jun 28, 2010 at 9:40 AM, Wil  wrote:

> Hi again,
>
> I made a "real" request this time because in the previous one, I
> couldn't control the nonce and timestamp generation directly so I copy-
> pasted the code it used and modified it a bit. This is the "real"
> generated data which has a non-mock nonce and timestamp.
>
> Timestamp: "1277742686"
> Nonce: "ufywbndxv0qevuh0"
>
> Base String:
>
> POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> %3DTwitterConsumerKey%26oauth_nonce
> %3Dufywbndxv0qevuh0%26oauth_signature_method%3DHMAC-
> SHA1%26oauth_timestamp%3D1277742686%26oauth_token%3DTwitterAccessToken
> %26oauth_version%3D1.0%26source%3DWildfire%2520by%2520Implication
>
> Signature:
> YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D
>
> Packet Capture:
> - Http: Request, POST /1/statuses/filter.json , Using OAuth
> Authorization
>Command: POST
>  + URI: /1/statuses/filter.json
>ProtocolVersion: HTTP/1.1
>  - Authorization: OAuth
>   + Authorization:  OAuth
>
> oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oauth_nonce="ufywbndxv0qevuh0",oauth_timestamp="1277742686",oauth_signature_method="HMAC-
> SHA1",oauth_signature="YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D",oauth_version="1.0",
>   + ContentType:  application/x-www-form-urlencoded
>Host:  stream.twitter.com
>ContentLength:  51
>
> - Http: HTTP Payload, URL: /1/statuses/filter.json
>  - payload: HttpContentType =  application/x-www-form-urlencoded
>  source: Wildfire%20by%20Implication
> follow: 156934710
>
>
> It still looks correct though...
>
> Regards,
> Wil
>
> On Jun 29, 12:21 am, Wil  wrote:
> > Hi,
> >
> > I got exactly the same values:
> >
> > Base string:
> > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > %3DTwitterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method
> > %3DHMAC-SHA1%26oauth_timestamp%3D1277739588%26oauth_token
> > %3DTwitterAccessToken%26oauth_version%3D1.0%26source%3DWildfire%2520by
> > %2520Implication
> >
> > Signature (escaped):
> > rYGiA6H2UXog0nYOzTeUKwJSssM%3D
> >
> > Authorization Header:
> >
> oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oa
> uth_nonce="abcdefgh",oauth_timestamp="1277739588",oauth_signature_method="H
> MAC-
> > SHA1",oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM
> > %3D",oauth_version="1.0"
> >
> > Post content:
> > source=Wildfire%20by%20Implication&follow=156934710
> >
> > On Jun 28, 11:45 pm, Taylor Singletary 
> > wrote:
> >
> >
> >
> > > Let's start from a common point. By using the same inputs, we can try
> and
> > > meet in the middle with exactly the same signature, signature base
> string,
> > > and authorization header.
> >
> > > Using the following values:
> > > Consumer Key: TwitterConsumerKey
> > > Consumer Secret: TwitterConsumerSecret
> > > Access Token: TwitterAccessToken
> > > Access Token Secret: TwitterAccessTokenScret
> > > OAuth Nonce: abcdefgh
> > > OAuth Timestamp: 1277739588
> >
> > > URL:http://stream.twitter.com/1/statuses/filter.json
> >
> > > POST Body:
> > > follow=156934710&source=Wildfire%20by%20Implication
> >
> > > Assuming these exact values, the following should be the result:
> >
> > > POST body:
> > > follow=156934710&source=Wildfire%20by%20Implication
> >
> > > Signature Base String:
> > > POST&http%3A%2F%2Fstream.twitter.com
> > >
> %2F1%2Fstatuses%2Ffilter.json&follow%3D156934710%26oauth_consumer_key%3DTwi
> tterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method%3DHMAC-SH
> A1%26oauth_timestamp%3D1277739588%26oauth_token%3DTwitterAccessToken%26oaut
> h_version%3D1.0%26source%3DWildfire%2520by%2520Implication
> >
> > > Signing Secret
> > > TwitterConsumerSecret&TwitterAccessTokenSecret
> >
> > > Signature
> > > rYGiA6H2UXog0nYOzTeUKwJSssM=
> >
> > > Authorization Header
> > > OAuth oauth_nonce="abcdefgh", oauth_signature_method="HMAC-SHA1",
> > > oauth_timestamp="1277739588", oauth_consumer_key="TwitterConsumerKey",
> > > oauth_token="TwitterAccessToken",
> > > oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM%3D", oauth_version="1.0"
> >
> > > Using these values do you get the same signature and other values?
> >
> > > Taylor
> >
> > > On Mon, Jun 28, 2010 at 8:21 AM, Wil  wrote:
> > > > Oh wait, it does include them I just missed it.
> >
> > > > So much for premature celebration...
> >
> > > > On Jun 28, 11:10 pm, Wil  wrote:
> > > > > The thing wasn't including the POST parameters in the signing! I
> think
> > > > > I got it!
> >
> > > > > On Jun 28, 10:54 pm, Wil  wrot

Re: [twitter-dev] Re: Get username from Twitter API

[Taylor Singletary]

Hi Emerson,

OAuth doesn't change any of our policies related to this area. Our policies
on "get more followers" kind of sites is expressed here:
http://help.twitter.com/entries/68916-following-rules-and-best-practices and
here: http://help.twitter.com/forums/26257/entries/18311

Taylor

2010/6/28 Emerson Damasceno 

> Hello there,
> I'm speaking on behalf of a third-party Brazilian site that wishes to use
> OAuth, I ask you these following questions:
> 1. The site is a "Get more Followers" kind. In the past had been some
> issues using OAuth, so the site discontinued that.
> 2. Is there any problem for this kind of service after the Change to OAuth,
> on June 30th?
> 3. If so, what exactly would be necessary to avoid those reported issues?
>
> I remain waiting for your answer.
> Thanks a lot.
> Kind yours,
>
> Emerson Damasceno
> twitter.com/emersonanomia
>
> 2010/6/28 thomas 
>
> Excellent Taylor
>>
>> Thanks a lot
>>
>> I was going crazy with this
>>
>> On 28 Ιούν, 17:19, Taylor Singletary 
>> wrote:
>> > Hi Thomas,
>> >
>> > There are a few ways you retrieve this information. When you are on the
>> > final leg of your OAuth transaction (exchanging a request token for an
>> > access token), part of the response that you get back includes the user
>> id
>> > and screen name for the authenticating user:
>> >
>> >
>> oauth_token=819797-Jxq8aYUDRmykzVKrgoLhXSq67TEa5ruc4GJC2rWimw&oauth_token_s­ecret=J6zix3FfA9LofH0awS24M3HcBYXO5nI1iYe8EfBA&user_id=819797&screen_name=e­pisod
>> >
>> > (Notice both "screen_name" and "user_id" keys)
>> >
>> > You can also make an OAuth authenticated call tohttp://
>> api.twitter.com/1/account/verify_credentials.xmland receive the
>> > information you're looking for back in either XML or JSON format.
>> >
>> > Taylor
>> >
>> >
>> >
>> > On Mon, Jun 28, 2010 at 7:02 AM, thomas  wrote:
>> > > Hi all,
>> >
>> > > I have created a Twitter app using oAuth for authentication.
>> >
>> > > However, I cannot find any info on how I can retrieve the user's
>> > > username in order to get his details. By user, I mean the one that
>> > > granted my app permission and for whom the app is making the API calls
>> >
>> > > Thank you
>
>
>
>
> --
> Emerson Damasceno
> www.twitter.com/emersonanomia
> www.facebook.com/emersondamasceno
>

[twitter-dev] Re: Streaming API OAuth explanation?

[Wil]

Hi Taylor,

Finally! It now works. TweetSharp includes the source parameter by
default on all requests (I think). Thus, I overrode the
TwitterClientInfo just for that request and cleared out the
"ClientName" field. Now it works!

I guess on your side, the code filters out unknown parameters before
doing the signature verification thing huh?

Thanks a lot for helping! (though TweetSharp has another problem of
dropping off the stream connection prematurely... that's another topic
to discuss after I do more poking)

Regards,
Wil

On Jun 29, 12:49 am, Taylor Singletary 
wrote:
> Hi Wil,
>
> Did some more tests. Why are you passing source in this context? I don't
> recall this being an operator for the Streaming API. If you're passing it as
> some kind of analogue to a source parameter you'd pass in basic auth on
> tweet creation, it's unnecessary here unless there's some other use for it
> that I'm unaware of. Without the source parameter, I'm able to make this
> call work.
>
> Taylor
>
>
>
> On Mon, Jun 28, 2010 at 9:40 AM, Wil  wrote:
> > Hi again,
>
> > I made a "real" request this time because in the previous one, I
> > couldn't control the nonce and timestamp generation directly so I copy-
> > pasted the code it used and modified it a bit. This is the "real"
> > generated data which has a non-mock nonce and timestamp.
>
> > Timestamp: "1277742686"
> > Nonce: "ufywbndxv0qevuh0"
>
> > Base String:
>
> > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > %3DTwitterConsumerKey%26oauth_nonce
> > %3Dufywbndxv0qevuh0%26oauth_signature_method%3DHMAC-
> > SHA1%26oauth_timestamp%3D1277742686%26oauth_token%3DTwitterAccessToken
> > %26oauth_version%3D1.0%26source%3DWildfire%2520by%2520Implication
>
> > Signature:
> > YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D
>
> > Packet Capture:
> > - Http: Request, POST /1/statuses/filter.json , Using OAuth
> > Authorization
> >    Command: POST
> >  + URI: /1/statuses/filter.json
> >    ProtocolVersion: HTTP/1.1
> >  - Authorization: OAuth
> >   + Authorization:  OAuth
>
> > oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oa 
> > uth_nonce="ufywbndxv0qevuh0",oauth_timestamp="1277742686",oauth_signature_m 
> > ethod="HMAC-
> > SHA1",oauth_signature="YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D",oauth_version="1.0",
> >   + ContentType:  application/x-www-form-urlencoded
> >    Host:  stream.twitter.com
> >    ContentLength:  51
>
> > - Http: HTTP Payload, URL: /1/statuses/filter.json
> >  - payload: HttpContentType =  application/x-www-form-urlencoded
> >      source: Wildfire%20by%20Implication
> >     follow: 156934710
>
> > It still looks correct though...
>
> > Regards,
> > Wil
>
> > On Jun 29, 12:21 am, Wil  wrote:
> > > Hi,
>
> > > I got exactly the same values:
>
> > > Base string:
> > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > %3DTwitterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method
> > > %3DHMAC-SHA1%26oauth_timestamp%3D1277739588%26oauth_token
> > > %3DTwitterAccessToken%26oauth_version%3D1.0%26source%3DWildfire%2520by
> > > %2520Implication
>
> > > Signature (escaped):
> > > rYGiA6H2UXog0nYOzTeUKwJSssM%3D
>
> > > Authorization Header:
>
> > oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oa
> > uth_nonce="abcdefgh",oauth_timestamp="1277739588",oauth_signature_method="H
> > MAC-
> > > SHA1",oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM
> > > %3D",oauth_version="1.0"
>
> > > Post content:
> > > source=Wildfire%20by%20Implication&follow=156934710
>
> > > On Jun 28, 11:45 pm, Taylor Singletary 
> > > wrote:
>
> > > > Let's start from a common point. By using the same inputs, we can try
> > and
> > > > meet in the middle with exactly the same signature, signature base
> > string,
> > > > and authorization header.
>
> > > > Using the following values:
> > > > Consumer Key: TwitterConsumerKey
> > > > Consumer Secret: TwitterConsumerSecret
> > > > Access Token: TwitterAccessToken
> > > > Access Token Secret: TwitterAccessTokenScret
> > > > OAuth Nonce: abcdefgh
> > > > OAuth Timestamp: 1277739588
>
> > > > URL:http://stream.twitter.com/1/statuses/filter.json
>
> > > > POST Body:
> > > > follow=156934710&source=Wildfire%20by%20Implication
>
> > > > Assuming these exact values, the following should be the result:
>
> > > > POST body:
> > > > follow=156934710&source=Wildfire%20by%20Implication
>
> > > > Signature Base String:
> > > > POST&http%3A%2F%2Fstream.twitter.com
>
> > %2F1%2Fstatuses%2Ffilter.json&follow%3D156934710%26oauth_consumer_key%3DTwi
> > tterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method%3DHMAC-SH
> > A1%26oauth_timestamp%3D1277739588%26oauth_token%3DTwitterAccessToken%26oaut
> > h_version%3D1.0%26source%3DWildfire%2520by%2520Implication
>
> > > > Signing Secret
> > > > TwitterConsumerSecret&TwitterAccessTokenSecret
>
> > > > Signature
> > > > rYGiA6H2UXog0nYOzTeUKwJSssM=

[twitter-dev] increase rate limit

[pranay]

hello guys,
I am using twitter API to get the information about
users.However, there are some limit dor call rewuest of 150 request
per hour.how can I increase API call rate limit?.. Thank you

Re: [twitter-dev] When will be supported UTF-8 encoding support in Twitter Streaming API?

[M. Edward (Ed) Borasky]

Quoting John Kalucki :


We don't have current plans to fix this issue. The problem isn't around
utf-8, but rather around non-space separated languages. Our language
processing experts described the effort required, and it's a pretty large
project, and may be computationally impractical in the current streaming
architecture. There is a workaround, albeit a generally impractical one:
take the firehose and perform the language parsing on your end.

-John Kalucki
http://twitter.com/jkalucki
Twitter Inc.


Is there a "canonical list" of non-space-separated languages? I'm just  
starting to look into this myself. There's quite a bit of research  
available for Chinese, but what are the others? And while we're on the  
subject, how about right-to-left languages?


Yes, it's a large project, but CJK and Arabic represent large  
*markets* too. I can understand Twitter needing to prioritize  
engineering resources, but the marketer in me says such problems could  
be solved with the application of money and a Twitter lab somewhere in  
east Asia. ;-)



On Mon, Jun 28, 2010 at 1:34 AM, sjoonk  wrote:


I know current Twitter Streaming API do not support utf-8 track
keyword.
As an CJK engineer, I hope this feature will implemented so soon.
Does anybody know when will be supported this feature in Twitter
Streaming API??

[twitter-dev] Re: increase rate limit

[Nik Fletcher]

Hi there

150 requests per hour is the limit for Basic Authentication-based
requests, with OAuth-authenticated requests allowed further requests.
Normally it's 350 (and is due to be raised to 1,500 per hour at some
stage), however given the extra load Twitter's under during the World
Cup OAuth requests are limited to 175 requests per hour (so, a 50%
reduction).

If you want to get the higher request rate, you'll need to use OAuth
to authenticate users - though I'd note that you'll likely see a fair
amount of latency and timeline issues with the OAuth home_timeline
method as that's seen the brunt of the extra World Cup API load in my
experience over the last week or so.

Twitter has all the documentation you need at:

http://dev.twitter.com

and there's likely a library to help with the OAuth stuff (definitely
for PHP, Objective-C) should you need it.

Cheers

@nikf

On Jun 28, 6:12 pm, pranay  wrote:
> hello guys,
>                 I am using twitter API to get the information about
> users.However, there are some limit dor call rewuest of 150 request
> per hour.how can I increase API call rate limit?.. Thank you

[twitter-dev] Re: since_id confusion

[Orian Marx (@orian)]

Try calling without the count parameter. The page and count parameters
may not work properly with since_id, and since_id may not work
properly if the id you pass results in too many tweets. :/

On Jun 27, 3:17 am, Terence Eden  wrote:
> To make this slightly clearer Imagine I have retrieved a page with
> 20 statuses.  Status IDs are
>
> 60 ... 40
>
> Calling the timeline with max_id=40&count=20 allows me to step back in
> time.  It gives me
>
> 40 ... 20
>
> Suppose I just want to see *next* 20 tweets since status_id 60?
> I would expect calling the timeline with since_id=60&count=20 to give
> me
>
> 80 ... 60
>
> It doesn't.  It gives me
> 100 ... 80.
> That is, the 20 most recent tweets from *now*.  I want the reverse of
> that.  The 20 tweets from *since_id*.
>
> Is there any way to get that?  I don't want to call the 200 most
> recent tweets and try to find the 20 I'm looking for, partly on
> bandwidth & processing grounds, but also, if the user is, say, 300
> tweets deep into their timeline, they'll miss tweets.
>
> Thanks
>
> Terence
>
> On Jun 26, 3:52 pm, Terence Eden  wrote:
>
> > Am I mistaken in how since_id works?
>
> > Callinghttp://api.twitter.com/1/statuses/home_timeline.json?count=20&max_id=...
> > Gives me the *next* 20 tweets from 1234
>
> > However, calling with 
> > since_idhttp://api.twitter.com/1/statuses/home_timeline.json?count=20&since_i...
> > Gives me the *first* 20 tweets in the timeline.  I was expecting it to
> > show the 20 tweets *from* 1234
>
> > Am I the only one with this confusion? Or is there a better way to
> > just retrieve the first 20 tweets which have occurred since?
>
> > Thanks
>
> > T
> > (Essentially, I'm implementing older and newer buttons which always
> > show older/newer tweets, rather than pages.)

Re: [twitter-dev] Re: Streaming API OAuth explanation?

[Matt Harris]

Wil,

Fantastic. So glad you got it working, and thanks for sharing the solution
which worked for you.

Matt

On Mon, Jun 28, 2010 at 10:10 AM, Wil  wrote:

> Hi Taylor,
>
> Finally! It now works. TweetSharp includes the source parameter by
> default on all requests (I think). Thus, I overrode the
> TwitterClientInfo just for that request and cleared out the
> "ClientName" field. Now it works!
>
> I guess on your side, the code filters out unknown parameters before
> doing the signature verification thing huh?
>
> Thanks a lot for helping! (though TweetSharp has another problem of
> dropping off the stream connection prematurely... that's another topic
> to discuss after I do more poking)
>
> Regards,
> Wil
>
> On Jun 29, 12:49 am, Taylor Singletary 
> wrote:
> > Hi Wil,
> >
> > Did some more tests. Why are you passing source in this context? I don't
> > recall this being an operator for the Streaming API. If you're passing it
> as
> > some kind of analogue to a source parameter you'd pass in basic auth on
> > tweet creation, it's unnecessary here unless there's some other use for
> it
> > that I'm unaware of. Without the source parameter, I'm able to make this
> > call work.
> >
> > Taylor
> >
> >
> >
> > On Mon, Jun 28, 2010 at 9:40 AM, Wil  wrote:
> > > Hi again,
> >
> > > I made a "real" request this time because in the previous one, I
> > > couldn't control the nonce and timestamp generation directly so I copy-
> > > pasted the code it used and modified it a bit. This is the "real"
> > > generated data which has a non-mock nonce and timestamp.
> >
> > > Timestamp: "1277742686"
> > > Nonce: "ufywbndxv0qevuh0"
> >
> > > Base String:
> >
> > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > %3DTwitterConsumerKey%26oauth_nonce
> > > %3Dufywbndxv0qevuh0%26oauth_signature_method%3DHMAC-
> > > SHA1%26oauth_timestamp%3D1277742686%26oauth_token%3DTwitterAccessToken
> > > %26oauth_version%3D1.0%26source%3DWildfire%2520by%2520Implication
> >
> > > Signature:
> > > YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D
> >
> > > Packet Capture:
> > > - Http: Request, POST /1/statuses/filter.json , Using OAuth
> > > Authorization
> > >Command: POST
> > >  + URI: /1/statuses/filter.json
> > >ProtocolVersion: HTTP/1.1
> > >  - Authorization: OAuth
> > >   + Authorization:  OAuth
> >
> > >
> oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oa
> uth_nonce="ufywbndxv0qevuh0",oauth_timestamp="1277742686",oauth_signature_m
> ethod="HMAC-
> > >
> SHA1",oauth_signature="YRXJUMYs0bRzkDZSTXesGfIWhQ8%3D",oauth_version="1.0",
> > >   + ContentType:  application/x-www-form-urlencoded
> > >Host:  stream.twitter.com
> > >ContentLength:  51
> >
> > > - Http: HTTP Payload, URL: /1/statuses/filter.json
> > >  - payload: HttpContentType =  application/x-www-form-urlencoded
> > >  source: Wildfire%20by%20Implication
> > > follow: 156934710
> >
> > > It still looks correct though...
> >
> > > Regards,
> > > Wil
> >
> > > On Jun 29, 12:21 am, Wil  wrote:
> > > > Hi,
> >
> > > > I got exactly the same values:
> >
> > > > Base string:
> > > > POST&http%3A%2F%2Fstream.twitter.com%2F1%2Fstatuses
> > > > %2Ffilter.json&follow%3D156934710%26oauth_consumer_key
> > > >
> %3DTwitterConsumerKey%26oauth_nonce%3Dabcdefgh%26oauth_signature_method
> > > > %3DHMAC-SHA1%26oauth_timestamp%3D1277739588%26oauth_token
> > > >
> %3DTwitterAccessToken%26oauth_version%3D1.0%26source%3DWildfire%2520by
> > > > %2520Implication
> >
> > > > Signature (escaped):
> > > > rYGiA6H2UXog0nYOzTeUKwJSssM%3D
> >
> > > > Authorization Header:
> >
> > >
> oauth_consumer_key="TwitterConsumerKey",oauth_token="TwitterAccessToken",oa
> > >
> uth_nonce="abcdefgh",oauth_timestamp="1277739588",oauth_signature_method="H
> > > MAC-
> > > > SHA1",oauth_signature="rYGiA6H2UXog0nYOzTeUKwJSssM
> > > > %3D",oauth_version="1.0"
> >
> > > > Post content:
> > > > source=Wildfire%20by%20Implication&follow=156934710
> >
> > > > On Jun 28, 11:45 pm, Taylor Singletary  >
> > > > wrote:
> >
> > > > > Let's start from a common point. By using the same inputs, we can
> try
> > > and
> > > > > meet in the middle with exactly the same signature, signature base
> > > string,
> > > > > and authorization header.
> >
> > > > > Using the following values:
> > > > > Consumer Key: TwitterConsumerKey
> > > > > Consumer Secret: TwitterConsumerSecret
> > > > > Access Token: TwitterAccessToken
> > > > > Access Token Secret: TwitterAccessTokenScret
> > > > > OAuth Nonce: abcdefgh
> > > > > OAuth Timestamp: 1277739588
> >
> > > > > URL:http://stream.twitter.com/1/statuses/filter.json
> >
> > > > > POST Body:
> > > > > follow=156934710&source=Wildfire%20by%20Implication
> >
> > > > > Assuming these exact values, the following should be the result:
> >
> > > > > POST body:
> > > > > follow=156934710&source=Wildfire%20by%20Implication
> >
> > > > > Signature Base String:
> > > > > POST&http%3A%2F%2Fstream.twitter.com
> >