[twitter-dev] 401 unauthorized

[Ken W]

My previous post is waiting to be moderated since I'm a newbie I
think, but I was wrong. I thought it was a get vs. post issue, but it
seems to be that my code works very intermittently. The error is
always a 401 unauthorized in getting the access token from the request
token. but once in a while it works fine. I'm using the Ruby tutorial
from the wiki pretty much verbatim for now. To get it to work
initially I had to add the authorize url to the oauth::consumer new
call (rather than use the defaults) but that may have just been the
intermittent nature.
I'd like to debug this myself but I can't see where the authorize
would ever return a 401 since I just got the request token (I can see
where the previous step would return unauthorized if the user denied
or some error occurred there). Anywhere I can look for hints? Could it
be something about the fact I have rtied and failed a few times? I
don't think I could have hit any reasonable limit.
Ken

[twitter-dev] Re: OAuth and screen name

[Dossy Shiobara]

On 4/17/09 7:19 PM, Doug Williams wrote:

Matt has done an amazing job this week. Just want to throw it out there
that I'm super impressed.

Now... to drop Sign in with Twitter around the web.


It's now available on Twitter Karma!  I'm still allowing folks to use 
their Twitter user/password and HTTP Basic Auth. just in case, but it's 
there.


Matt, you really kicked ass this week w/ OAuth.  Thanks!

--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth and screen name

[Petermdenton]

Yeah Matt's the Donald Trump of releases. He looks a task or bug,  
right in the eye, points:

"you're fired."

On Apr 17, 2009, at 4:19 PM, Doug Williams  wrote:

Matt has done an amazing job this week. Just want to throw it out  
there that I'm super impressed.


Now... to drop Sign in with Twitter around the web.

Doug Williams
Twitter API Support
http://twitter.com/dougw


On Fri, Apr 17, 2009 at 2:45 PM, Dossy Shiobara   
wrote:


On 4/17/09 5:28 PM, Matt Sanford wrote:
It's working fine for me, and it sounds like for Abraham as well.
Perhaps some more details about how you're calling it would help. Go
ahead and fill out a bug report [1] with the headers and whatnot and
I'll take a look.

Done!  Thanks.

http://code.google.com/p/twitter-api/issues/detail?id=478


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
 "He realized the fastest way to change is to laugh at your own
   folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: What precisely does notification mean?

[Doug Williams]

Allen,
Notifications are for device notifications (like SMS or IM) if the user has
them enabled. Following means that a user's updates are included in your
timeline. Notifications mean that a user's updates appear in your timeline
AND are sent to your enabled devices.

Doug Williams
Twitter API Support
http://twitter.com/dougw


On Fri, Apr 17, 2009 at 3:13 PM, Allen  wrote:

>
> Seeing all the posts here, I'm getting confused as to what the term
> notification means.  Does it mean, for example:
>
> a)  the person has it enabled to get email when someone starts
> following them
>
> b) the person has it enabled to notices sent to their mobile phone
>
> c)  something else?
>
> Seriously, I've seen the term used in different contexts and the api
> says "Enables notifications for updates from the specified user to the
> authenticating user.  Returns the specified user when successful." but
> then it says that notification is a "boolean indicating if a user is
> receiving device updates for a given user", which sounds like it's a
> mobile phone (i.e., device).
>
> Can anybody clarify what this is?
>
> Thanks
> Allen
>

[twitter-dev] Re: OAuth and screen name

[Doug Williams]

Matt has done an amazing job this week. Just want to throw it out there that
I'm super impressed.

Now... to drop Sign in with Twitter around the web.

Doug Williams
Twitter API Support
http://twitter.com/dougw


On Fri, Apr 17, 2009 at 2:45 PM, Dossy Shiobara  wrote:

>
> On 4/17/09 5:28 PM, Matt Sanford wrote:
>
>> It's working fine for me, and it sounds like for Abraham as well.
>> Perhaps some more details about how you're calling it would help. Go
>> ahead and fill out a bug report [1] with the headers and whatnot and
>> I'll take a look.
>>
>
> Done!  Thanks.
>
> http://code.google.com/p/twitter-api/issues/detail?id=478
>
>
> --
> Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>  "He realized the fastest way to change is to laugh at your own
>folly -- then you can let go and quickly move on." (p. 70)
>

[twitter-dev] Re: To link the @ or not to link the @, that is the question

[Chad Etzel]

On Fri, Apr 17, 2009 at 6:36 PM, Nick Arnett  wrote:
>
> Perhaps it helps to think about a tool that extracts the tagged text from
> links.  Would it make sense to end up with text that omits the @ sign?  Not
> really,

I disagree.  There's really nothing useful about the @ sign except to
signify that you are referencing a username.  The only meaningful way
to use the data is to just use the text part (e.g. create a link to
their twitter profile, or do a lookup in an app database, etc), so
having to further remove the @ sign that a tool might hand me is a
waste of cycles, imho.  If you really want a username with an @ in
front of it, it's trivial to tack it on the front.

I can see your protocol argument, but in this case, it's not really a
protocol but a convention signifier, and I think it's more
aesthetically pleasing to have it unlinked (again, personal opinion).

I wonder what drove this decision for the twitter UI team when they
decided to link usernames on the main site?

-Chad

[twitter-dev] Re: To link the @ or not to link the @, that is the question

[Nick Arnett]

On Fri, Apr 17, 2009 at 7:21 AM, Chad Etzel  wrote:

>
> A more lighthearted discussion to see where people stand on this
> convention.
>
> We all know the convention of prefixing usernames with the @ symbol,
> the interesting thing I notice is that different sites (and even
> within tiwtter's site itself) decide to link or not link the @ symbol
> along with it.


Been thinking about this.  Not linking the @ sign feels a bit like not
linking "http://"; at the beginning of an automatically linked URL. On the
other hand, @ is not a protocol, which might be an argument against linking
it.  But just as some clients automatically link URLs, some clients are
already smart enough to create a link to Twitter if they see a word starting
with @ and no space after it... though of course the protocol is still HTTP.
 It is sort of an extended protocol... tells the client the protocol plus
the domain.

Perhaps it helps to think about a tool that extracts the tagged text from
links.  Would it make sense to end up with text that omits the @ sign?  Not
really, so I favor including it.

Nick

[twitter-dev] Re: To link the @ or not to link the @, that is the question

[Abraham Williams]

This is something else that could go on a "best practices" page on the
apiwiki.

On Fri, Apr 17, 2009 at 15:50, Doug Williams  wrote:

> I agree. I'm all for convention... It helps users navigate and build
> confidence in the Twitter experience, where ever it may be.
>
> Doug Williams
> Twitter API Support
> http://twitter.com/dougw
>
>
>
> On Fri, Apr 17, 2009 at 7:45 AM, Abraham Williams <4bra...@gmail.com>wrote:
>
>> I don't link the @ sign because 1) I don't like how it looks and 2)
>> Twitter.com does not.
>>
>>
>> On Fri, Apr 17, 2009 at 09:21, Chad Etzel  wrote:
>>
>>>
>>> A more lighthearted discussion to see where people stand on this
>>> convention.
>>>
>>> We all know the convention of prefixing usernames with the @ symbol,
>>> the interesting thing I notice is that different sites (and even
>>> within tiwtter's site itself) decide to link or not link the @ symbol
>>> along with it.
>>>
>>> Main twitter site: is NOT linked
>>> search.twitter.com: IS linked
>>> new twitter integrated sidebar search: IS linked (i suppose this uses
>>> the same code as search.twitter)
>>>
>>> TweetGrid: is NOT linked
>>> Tweetie: IS linked
>>> etc..
>>>
>>> just curious how people decided which convention to use.
>>>
>>> From a visual perspective I prefer having the @ be plaintext since it
>>> provides a nice visual difference looking at word, whereas normal
>>> links are bounded by whitespace.  This makes the usernames pop out (to
>>> my eyes anyway).
>>>
>>> -Chad
>>>
>>
>>
>>
>> --
>> Abraham Williams | http://the.hackerconundrum.com
>> Hacker | http://abrah.am | http://twitter.com/abraham
>> Web608 | Community Evangelist | http://web608.org
>> This email is: [ ] blogable [x] ask first [ ] private.
>> Sent from Madison, Wisconsin, United States
>
>
>


-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] What precisely does notification mean?

[Allen]

Seeing all the posts here, I'm getting confused as to what the term
notification means.  Does it mean, for example:

a)  the person has it enabled to get email when someone starts
following them

b) the person has it enabled to notices sent to their mobile phone

c)  something else?

Seriously, I've seen the term used in different contexts and the api
says "Enables notifications for updates from the specified user to the
authenticating user.  Returns the specified user when successful." but
then it says that notification is a "boolean indicating if a user is
receiving device updates for a given user", which sounds like it's a
mobile phone (i.e., device).

Can anybody clarify what this is?

Thanks
Allen

[twitter-dev] Re: OAuth and screen name

[Dossy Shiobara]

On 4/17/09 5:28 PM, Matt Sanford wrote:

 It's working fine for me, and it sounds like for Abraham as well.
Perhaps some more details about how you're calling it would help. Go
ahead and fill out a bug report [1] with the headers and whatnot and
I'll take a look.


Done!  Thanks.

http://code.google.com/p/twitter-api/issues/detail?id=478

--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth and screen name

[Matt Sanford]

Hi Dossy,

It's working fine for me, and it sounds like for Abraham as well.  
Perhaps some more details about how you're calling it would help. Go  
ahead and fill out a bug report [1] with the headers and whatnot and  
I'll take a look.


Thanks;
  — Matt

[1] - http://code.google.com/p/twitter-api/issues/entry

On Apr 17, 2009, at 02:17 PM, Dossy Shiobara wrote:



On 4/17/09 4:58 PM, Matt Sanford wrote:

Totally right, we just deployed the change. The method now calls the
callback with the request token and that token can be exchanged for
the existing access token.


OMG awesome!  Thank you SO much for the quick turn-around, Matt.

Now, can someone help investigate why I keep getting HTTP 500  
responses to my OAuth requests?  (FYI, HTTP Basic Auth requests for  
the same users succeed just fine.)


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
 "He realized the fastest way to change is to laugh at your own
   folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth and screen name

[Dossy Shiobara]

On 4/17/09 4:58 PM, Matt Sanford wrote:

Totally right, we just deployed the change. The method now calls the
callback with the request token and that token can be exchanged for
the existing access token.


OMG awesome!  Thank you SO much for the quick turn-around, Matt.

Now, can someone help investigate why I keep getting HTTP 500 responses 
to my OAuth requests?  (FYI, HTTP Basic Auth requests for the same users 
succeed just fine.)


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Tweet Corpus creation for NLP research

[Nicole Simon]

Anything you can do to help people determine better the language of tweets,
so search is more usable for international users. ;))

I am a bit curious about the mentioned 'costs of publishing in journals
and conferences' - don't know about the journals. but none of the
conferences I know of in Tech would charge anybody for presenting
such kind of results. As long as you are not a boring academic speaker
this should be interesting enough for some of the major tech ones.

(it makes it easier if you can bring a specific dev or biz angle)

Nicole

[twitter-dev] Re: OAuth and screen name

[Matt Sanford]

Hello all,

Totally right, we just deployed the change. The method now calls  
the callback with the request token and that token can be exchanged  
for the existing access token. I have been away from email getting the  
fix tested and deployed or I would have responded sooner. This fixes  
the major issue (token guessing) there are still a few side issues  
that we need to hash out. The main ones being:


 • As a convenience we provide screen_name and user_id … these  
could be changed on a URL via a man-in-the-middle. An easy fix it to  
take away the convenience and go back to making people call  
verify_credentials. In all likelihood we'll end up having to do that.


 • A man-in-the-middle could change any other URL parameters during  
the redirect back to the application. That URL information is not  
signed in any way.


 • This all seems to be very close to what OpenID offers. I've been  
siding with Eran [1] but we may find compelling reasons to add OpenID  
support in the future. We simply don't have the man-power to review  
what's needed for OpenID and implement it right now.


Thanks;
  — Matt Sanford / @mzsanford

[1] - http://www.hueniverse.com/hueniverse/2009/04/twitter-connect.html

On Apr 17, 2009, at 10:58 AM, djMax wrote:



You're such a tease!  I'm assuming that it's going to change by you
returning a request token and us exchanging it for the previous access
token like usual...  I understand you're probably not going to respond
to that.

(as an aside, we've implemented this in dev with a fallback so that if
the authenticate fails or returns unusable results, we just try
authorize instead)

On Apr 17, 11:10 am, Matt Sanford  wrote:

Hello again,

 Let me be more specific that my previous mails. This will be
changing. Let me emphasize that:

⚠ The new authenticate method will be changing in a way that breaks
the current behavior.

 At this point it is only a matter of time until I can get the  
new

code reviewed and deployed. I would suggest people hold off on the
authenticate method for the moment. I'll send more details once the
code is reviewed and we're sure it won't be delayed for some reason.

Thanks;
   — Matt Sanford

On Apr 17, 2009, at 06:26 AM, djMax wrote:




I believe this flow is not secure (or not "as" secure) because that
URL that is "transmitted" via the browser is permanently reusable by
anyone to login to my service as that twitter user.  In the
authorization flow, I don't believe any such URL ever goes through  
the

browser.


So basically I think the Twitter folks need to change the last  
step in

the flow to be an exchange of a request token to the original access
token by the app on the backend...



On Apr 17, 8:01 am, Dossy Shiobara  wrote:

On 4/17/09 2:51 AM, Abraham Williams wrote:



They correct flow is:
1) get request token from twitter.
2) send user to twitter with oauth_token for the first time.



Send the user to Twitter how, though?  oauth/authorize?  How do you
know
if this is the user's first time or not?


3) user returns and app uses request token to get user access  
token

which get stored.



This is fine, unless the user returns with an access token and not
the
original request token.  This is what currently happens with
oauth/authenticate.



4) user come back to site to sign in and is not signed in.
5) site gets request token from twitter.
6) user is sent to twitter with request oauth_token and are
automatically redirected back to site.
7) access oauth_token is returned with user which can be matched
with
oauth_token_secret stored in the database.


This would work fine, assuming in step #2 you had some way of  
knowing

whether a Twitter user had never previously OAuth authorized your
app.



--
Dossy Shiobara  | do...@panoptic.com |http://dossy.org/
Panoptic Computer Network   |http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: To link the @ or not to link the @, that is the question

[Doug Williams]

I agree. I'm all for convention... It helps users navigate and build
confidence in the Twitter experience, where ever it may be.

Doug Williams
Twitter API Support
http://twitter.com/dougw


On Fri, Apr 17, 2009 at 7:45 AM, Abraham Williams <4bra...@gmail.com> wrote:

> I don't link the @ sign because 1) I don't like how it looks and 2)
> Twitter.com does not.
>
>
> On Fri, Apr 17, 2009 at 09:21, Chad Etzel  wrote:
>
>>
>> A more lighthearted discussion to see where people stand on this
>> convention.
>>
>> We all know the convention of prefixing usernames with the @ symbol,
>> the interesting thing I notice is that different sites (and even
>> within tiwtter's site itself) decide to link or not link the @ symbol
>> along with it.
>>
>> Main twitter site: is NOT linked
>> search.twitter.com: IS linked
>> new twitter integrated sidebar search: IS linked (i suppose this uses
>> the same code as search.twitter)
>>
>> TweetGrid: is NOT linked
>> Tweetie: IS linked
>> etc..
>>
>> just curious how people decided which convention to use.
>>
>> From a visual perspective I prefer having the @ be plaintext since it
>> provides a nice visual difference looking at word, whereas normal
>> links are bounded by whitespace.  This makes the usernames pop out (to
>> my eyes anyway).
>>
>> -Chad
>>
>
>
>
> --
> Abraham Williams | http://the.hackerconundrum.com
> Hacker | http://abrah.am | http://twitter.com/abraham
> Web608 | Community Evangelist | http://web608.org
> This email is: [ ] blogable [x] ask first [ ] private.
> Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Tweet Corpus creation for NLP research

[jayb]

I've been collecting tweets for about a week for a project (http://
www.happn.in).

Some characteristics of my current dataset:
* Begin around April 10th 2009
* Collected from users who are located nearby 26 US cities
* ~5,000,000 tweets
* Growing at ~800,000 per day
* ~900MB in mysql
* ~375,000 users
* ~21,000 users in one sample city (Boston)

If you, kanny, or anyone else is interested in using them for research
or projects or anything else, let me know.

Jay

On Apr 8, 11:26 am, kanny  wrote:
> I am interested to do something deeper than the surface-level
> processing of a user's incoming tweets. For this, I will need to
> create a corpus of the user's friends_timeline over, say, past one
> month or any computationally feasible period. Basically, a large
> enough set of, say, 1-100 Million tweets for someone following
> 100-1000 people. It would be only a one-time download, as afterwards,
> incremental downloads should suffice.
>
> This would translate into 100MB-10 GB of download for a user. It could
> be less for people following less or less-active people. Does Twitter
> API provide support for such corpus creation ? It could be very
> helpful for Natural Language Processing research if Twitter creates
> some sample corpus of public_timeline or some selected user's
> timelines.
>
> Looking forward to some help in this regard.
> Thanks

[twitter-dev] Re: url as an input

[Abraham Williams]

The number of results you get is going to depend entirely on the url/users
and does not indicate which services is better.

On Fri, Apr 17, 2009 at 14:17, ParsePlz  wrote:

>
> I have already tried with backtweets API, it works but give lesser
> results than on-site search...
>
> On Apr 16, 12:45 am, ParsePlz  wrote:
> > Hi,
> >
> > could someone please post an example API request, I mean the url as
> > input, which api request to be used.
> >
> > I tried withhttp://search.twitter.com/search.atom?q=using tinyURL,
> > bitly even plain url, then with OR operator, but I dont get much as
> > (actually very few) backtweet results.
> >
> > What do you suggest me to use?
> >
> > How backtweers operate ??
> >
> > Thanks and Best Regards
> >
> > B. Parse
> >
> > On Apr 10, 4:15 am, Chris Thomson  wrote:
> >
> > > There's also the BackTweets API.http://backtweets.com/api
> >
> > > -Chris Thomson
> >
> > > On Thu, Apr 9, 2009 at 2:27 AM, jstrellner 
> wrote:
> >
> > > > Hi Nick,
> >
> > > > Yes, we can help with this. We have an API that is nearly complete
> > > > that will allow you to provide a URL and get all of the tweets that
> > > > contained a link to the provided URL, regardless of which URL
> > > > shortener that was used.
> >
> > > > -Joel
> >
> > > > On Apr 5, 12:02 pm, Nick Arnett  wrote:
> > > > > On Sun, Apr 5, 2009 at 11:44 AM, Abraham Williams <
> 4bra...@gmail.com>
> > > > wrote:
> > > > > > Just pretend the URL is text and search for that text using the
> default
> > > > > > Search API call.
> >
> > > > > But if you want meaningful results, you'll want to shorten the URL
> with
> > > > the
> > > > > popular shorteners (tinyurl, bitly, etc.) and search on the
> shortened
> > > > > versions.
> >
> > > > > Or you might be able to accomplish what you're seeking by using
> Twiturly.
> >
> > > > > Nick
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Tweet Corpus creation for NLP research

[Nick Arnett]

Part 1: http://drop.io/gmx85rd (tweetsgzaa) Part 2: http://drop.io/f5itrsx
 (tweetsgzab)

Password (for the download): twitter

The two parts need to be concatenated and then un-gzipped (naming the
concatenated file tweets.gz would be appropriate).

Nick


The format is a tab-delimited text file.  Fields are:
unix timestamp (seconds since 1970-01-01)
status ID
screen_name
status text

Let me know if you have any trouble with it.

Nick

[twitter-dev] Re: url as an input

[ParsePlz]

I have already tried with backtweets API, it works but give lesser
results than on-site search...

On Apr 16, 12:45 am, ParsePlz  wrote:
> Hi,
>
> could someone please post an example API request, I mean the url as
> input, which api request to be used.
>
> I tried withhttp://search.twitter.com/search.atom?q=using tinyURL,
> bitly even plain url, then with OR operator, but I dont get much as
> (actually very few) backtweet results.
>
> What do you suggest me to use?
>
> How backtweers operate ??
>
> Thanks and Best Regards
>
> B. Parse
>
> On Apr 10, 4:15 am, Chris Thomson  wrote:
>
> > There's also the BackTweets API.http://backtweets.com/api
>
> > -Chris Thomson
>
> > On Thu, Apr 9, 2009 at 2:27 AM, jstrellner  wrote:
>
> > > Hi Nick,
>
> > > Yes, we can help with this. We have an API that is nearly complete
> > > that will allow you to provide a URL and get all of the tweets that
> > > contained a link to the provided URL, regardless of which URL
> > > shortener that was used.
>
> > > -Joel
>
> > > On Apr 5, 12:02 pm, Nick Arnett  wrote:
> > > > On Sun, Apr 5, 2009 at 11:44 AM, Abraham Williams <4bra...@gmail.com>
> > > wrote:
> > > > > Just pretend the URL is text and search for that text using the 
> > > > > default
> > > > > Search API call.
>
> > > > But if you want meaningful results, you'll want to shorten the URL with
> > > the
> > > > popular shorteners (tinyurl, bitly, etc.) and search on the shortened
> > > > versions.
>
> > > > Or you might be able to accomplish what you're seeking by using 
> > > > Twiturly.
>
> > > > Nick

[twitter-dev] Re: OAuth and screen name

[Chris Messina]

I'm going to bring this up just to put this out there, but it really
seems to me that you should be using OpenID to authenticate the user
and OAuth for authorizing access to a user's account.

Given that any user can change their username at will, I worry that
app developers will rely on and *trust* the username provided by
Twitter when in fact that's really not what should be happening.

Perhaps this isn't the thread for it, but it seems to me that Twitter
should strongly consider adopting OpenID for authentication rather
than jerry-rigging it with OAuth.

I posted this concern to the OAuth list for discussion:

http://groups.google.com/group/oauth/browse_thread/thread/583720b6cc447e7b

Eran Hammer (author of the OAuth spec) also weighed in, in support of
Twitter's approach:

http://www.hueniverse.com/hueniverse/2009/04/twitter-connect.html

Chris

On Apr 17, 8:10 am, Matt Sanford  wrote:
> Hello again,
>
>      Let me be more specific that my previous mails. This will be  
> changing. Let me emphasize that:
>
> ⚠ The new authenticate method will be changing in a way that breaks  
> the current behavior.
>
>      At this point it is only a matter of time until I can get the new  
> code reviewed and deployed. I would suggest people hold off on the  
> authenticate method for the moment. I'll send more details once the  
> code is reviewed and we're sure it won't be delayed for some reason.
>
> Thanks;
>    — Matt Sanford
>
> On Apr 17, 2009, at 06:26 AM, djMax wrote:
>
>
>
>
>
> > I believe this flow is not secure (or not "as" secure) because that
> > URL that is "transmitted" via the browser is permanently reusable by
> > anyone to login to my service as that twitter user.  In the
> > authorization flow, I don't believe any such URL ever goes through the
> > browser.
>
> > So basically I think the Twitter folks need to change the last step in
> > the flow to be an exchange of a request token to the original access
> > token by the app on the backend...
>
> > On Apr 17, 8:01 am, Dossy Shiobara  wrote:
> >> On 4/17/09 2:51 AM, Abraham Williams wrote:
>
> >>> They correct flow is:
> >>> 1) get request token from twitter.
> >>> 2) send user to twitter with oauth_token for the first time.
>
> >> Send the user to Twitter how, though?  oauth/authorize?  How do you  
> >> know
> >> if this is the user's first time or not?
>
> >>> 3) user returns and app uses request token to get user access token
> >>> which get stored.
>
> >> This is fine, unless the user returns with an access token and not  
> >> the
> >> original request token.  This is what currently happens with
> >> oauth/authenticate.
>
> >>> 4) user come back to site to sign in and is not signed in.
> >>> 5) site gets request token from twitter.
> >>> 6) user is sent to twitter with request oauth_token and are
> >>> automatically redirected back to site.
> >>> 7) access oauth_token is returned with user which can be matched  
> >>> with
> >>> oauth_token_secret stored in the database.
>
> >> This would work fine, assuming in step #2 you had some way of knowing
> >> whether a Twitter user had never previously OAuth authorized your  
> >> app.
>
> >> --
> >> Dossy Shiobara              | do...@panoptic.com |http://dossy.org/
> >> Panoptic Computer Network   |http://panoptic.com/
> >>    "He realized the fastest way to change is to laugh at your own
> >>      folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Rate limit status's "remaining_hits" element scope

[Doug Williams]

It is the number of hits you have left until the reset-time is hit. So it's
part of that rolling window.





19933

2

2009-04-08T21:57:23+00:00

1239227843



Doug Williams
Twitter API Support
http://twitter.com/dougw


On Fri, Apr 17, 2009 at 6:27 AM, Dimebrain  wrote:

>
> I just realized I don't know whether the remaining_hits element
> returned for /account/rate_limit_status is a static number from the
> beginning of the current hour, or if it is the remaining hits on a
> rolling sixty minute cycle. Does anyone know?
>

[twitter-dev] Re: OAuth and screen name

[djMax]

You're such a tease!  I'm assuming that it's going to change by you
returning a request token and us exchanging it for the previous access
token like usual...  I understand you're probably not going to respond
to that.

(as an aside, we've implemented this in dev with a fallback so that if
the authenticate fails or returns unusable results, we just try
authorize instead)

On Apr 17, 11:10 am, Matt Sanford  wrote:
> Hello again,
>
>      Let me be more specific that my previous mails. This will be  
> changing. Let me emphasize that:
>
> ⚠ The new authenticate method will be changing in a way that breaks  
> the current behavior.
>
>      At this point it is only a matter of time until I can get the new  
> code reviewed and deployed. I would suggest people hold off on the  
> authenticate method for the moment. I'll send more details once the  
> code is reviewed and we're sure it won't be delayed for some reason.
>
> Thanks;
>    — Matt Sanford
>
> On Apr 17, 2009, at 06:26 AM, djMax wrote:
>
>
>
> > I believe this flow is not secure (or not "as" secure) because that
> > URL that is "transmitted" via the browser is permanently reusable by
> > anyone to login to my service as that twitter user.  In the
> > authorization flow, I don't believe any such URL ever goes through the
> > browser.
>
> > So basically I think the Twitter folks need to change the last step in
> > the flow to be an exchange of a request token to the original access
> > token by the app on the backend...
>
> > On Apr 17, 8:01 am, Dossy Shiobara  wrote:
> >> On 4/17/09 2:51 AM, Abraham Williams wrote:
>
> >>> They correct flow is:
> >>> 1) get request token from twitter.
> >>> 2) send user to twitter with oauth_token for the first time.
>
> >> Send the user to Twitter how, though?  oauth/authorize?  How do you  
> >> know
> >> if this is the user's first time or not?
>
> >>> 3) user returns and app uses request token to get user access token
> >>> which get stored.
>
> >> This is fine, unless the user returns with an access token and not  
> >> the
> >> original request token.  This is what currently happens with
> >> oauth/authenticate.
>
> >>> 4) user come back to site to sign in and is not signed in.
> >>> 5) site gets request token from twitter.
> >>> 6) user is sent to twitter with request oauth_token and are
> >>> automatically redirected back to site.
> >>> 7) access oauth_token is returned with user which can be matched  
> >>> with
> >>> oauth_token_secret stored in the database.
>
> >> This would work fine, assuming in step #2 you had some way of knowing
> >> whether a Twitter user had never previously OAuth authorized your  
> >> app.
>
> >> --
> >> Dossy Shiobara              | do...@panoptic.com |http://dossy.org/
> >> Panoptic Computer Network   |http://panoptic.com/
> >>    "He realized the fastest way to change is to laugh at your own
> >>      folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Updating icon for OAuth applications

[Abraham Williams]

follow the link Matt included marked with "[1]" and fill out the form.

On Fri, Apr 17, 2009 at 10:22, TweetPhoto  wrote:

>
> Hi Matt,
>
> Not sure how to open a "Google Code issue [1]" to fix the logo image
> issue.
>
> I will be more than happy to open it if you could let me know how.
>
> Thanks a million for getting that fixed!
>
> Sean
>
> On Apr 16, 7:49 am, Matt Sanford  wrote:
> > Hi Sean,
> >
> >  That's certainly a bug. We handle the case elsewhere on the site
> > correctly so this one must have been missed. Please open a Google Code
> > issue [1] so I don't forget to fix it.
> >
> > Thanks;
> >— Matt Sanford / @mzsanford
> >
> > [1] -
> http://code.google.com/p/twitter-api/issues/entry?template=Defect%20r...
> >
> > On Apr 16, 2009, at 04:25 AM, TweetPhoto wrote:
> >
> >
> >
> >
> >
> > > We're actually getting a different issue with the image.
> >
> > > When users visit our site, click on "Twitter Connect" or OAuth, if the
> > > user uses Internet Explorer, they get a message that says the logo on
> > > the Twitter login page is not secure. Do you want to download the non-
> > > secure items. I guess that image is not being hosted on an HTTPS and
> > > there is no way to change this as it's hosted at Twitter. Any thoughts
> > > guys?
> >
> > > Sean
> >
> > > On Apr 15, 12:40 pm, Jake Good  wrote:
> > >> I'm also having this issue: app id 1992...
> >
> > >> I've tried a PNG (7k) and a GIF (40k), including a twitter icon from
> > >> the twitter account (straight download)...
> >
> > >> Jake
> >
> > >> On Apr 15, 12:21 pm, Guan Yang  wrote:
> >
> > >>> I tried again just a few seconds ago. I tested with both my
> > >>> applications, 1396 and 1798.
> >
> > >>> Guan
> >
> > >>> 2009/4/15 Doug Williams :
> >
> >  Issue 374 [1] was supposed to fix this issue. When did you see
> >  this problem?
> >
> >  1.http://code.google.com/p/twitter-api/issues/detail?id=374
> >
> >  Doug Williams
> >  Twitter API Support
> > http://twitter.com/dougw
> >
> >  On Wed, Apr 15, 2009 at 12:56 AM, null  wrote:
> >
> > > hi Guan I have encounter this problem,but dont have solution for
> > > that
> >
> > > 在2009-04-15，"Guan Yang"  写道：
> >
> > > I have trouble updating the icon for my OAuth applications. I
> > > tried
> > > several different GIF and PNG files, much smaller than 700k and
> > > always
> > > get the error message:
> >
> > > Your application was registered, but there was a problem with your
> > > application image. Probably too big.
> >
> > > Has anyone else had this problem, or is it just that every image
> > > file
> > > on my computer is corrupted?
> >
> > > Guan
> >
> > > 
> > > 网易邮箱，中国第一大电子邮件服务商
> >
> > >>> --
> >
> > >>> Mitch Hedberg  - "I drank some boiling water because I wanted
> > >>> to
> > >>> whistle." -
> http://www.brainyquote.com/quotes/authors/m/mitch_hedberg.html-
> > >>>  Hide quoted text -
> >
> > >> - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Updating icon for OAuth applications

[TweetPhoto]

Hi Matt,

Not sure how to open a "Google Code issue [1]" to fix the logo image
issue.

I will be more than happy to open it if you could let me know how.

Thanks a million for getting that fixed!

Sean

On Apr 16, 7:49 am, Matt Sanford  wrote:
> Hi Sean,
>
>      That's certainly a bug. We handle the case elsewhere on the site  
> correctly so this one must have been missed. Please open a Google Code  
> issue [1] so I don't forget to fix it.
>
> Thanks;
>    — Matt Sanford / @mzsanford
>
> [1] -http://code.google.com/p/twitter-api/issues/entry?template=Defect%20r...
>
> On Apr 16, 2009, at 04:25 AM, TweetPhoto wrote:
>
>
>
>
>
> > We're actually getting a different issue with the image.
>
> > When users visit our site, click on "Twitter Connect" or OAuth, if the
> > user uses Internet Explorer, they get a message that says the logo on
> > the Twitter login page is not secure. Do you want to download the non-
> > secure items. I guess that image is not being hosted on an HTTPS and
> > there is no way to change this as it's hosted at Twitter. Any thoughts
> > guys?
>
> > Sean
>
> > On Apr 15, 12:40 pm, Jake Good  wrote:
> >> I'm also having this issue: app id 1992...
>
> >> I've tried a PNG (7k) and a GIF (40k), including a twitter icon from
> >> the twitter account (straight download)...
>
> >> Jake
>
> >> On Apr 15, 12:21 pm, Guan Yang  wrote:
>
> >>> I tried again just a few seconds ago. I tested with both my
> >>> applications, 1396 and 1798.
>
> >>> Guan
>
> >>> 2009/4/15 Doug Williams :
>
>  Issue 374 [1] was supposed to fix this issue. When did you see  
>  this problem?
>
>  1.http://code.google.com/p/twitter-api/issues/detail?id=374
>
>  Doug Williams
>  Twitter API Support
> http://twitter.com/dougw
>
>  On Wed, Apr 15, 2009 at 12:56 AM, null  wrote:
>
> > hi Guan I have encounter this problem,but dont have solution for  
> > that
>
> > 在2009-04-15，"Guan Yang"  写道：
>
> > I have trouble updating the icon for my OAuth applications. I  
> > tried
> > several different GIF and PNG files, much smaller than 700k and  
> > always
> > get the error message:
>
> > Your application was registered, but there was a problem with your
> > application image. Probably too big.
>
> > Has anyone else had this problem, or is it just that every image  
> > file
> > on my computer is corrupted?
>
> > Guan
>
> > 
> > 网易邮箱，中国第一大电子邮件服务商
>
> >>> --
>
> >>> Mitch Hedberg  - "I drank some boiling water because I wanted  
> >>> to
> >>> whistle." 
> >>> -http://www.brainyquote.com/quotes/authors/m/mitch_hedberg.html-
> >>>  Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] Re: Tweet Corpus creation for NLP research

[Nick Arnett]

I'm splitting it and putting it on drop.io.
Will take a little while to upload...  I'll post when it's available.

Nick

On Fri, Apr 17, 2009 at 9:17 AM, djMax  wrote:

>
> http://drop.io
>
> On Apr 17, 12:07 pm, Nick Arnett  wrote:
> > Michele, djMax and anybody else interested...  It is a 128MB file after
> > gzipping (291MB uncompressed).  Any thoughts on a place to put it for
> > download?  I'm reluctant to sacrifice a lot of my own bandwidth for this
> and
> > off the top of my head, I can't think of a good place to share it.
> > Nick
>

[twitter-dev] Re: 403 on valid request to friendships/create/ if friendship already exists

[Matt Sanford]

Woops, wrong 403 thread. My last two mails were about the search 403s.
Sorry about that.

— Matt

On Apr 17, 9:31 am, Matt Sanford  wrote:
> Hi all,
>
>      The issue with random HTTP 403s on search (both API and web)  
> should now be fixed. Similar to the employee password prompts a few  
> days ago we had a host unexpectedly join the search cluster. We want  
> more capacity so bad we're actually convincing inanimate objects to  
> join our cause. ¡Viva La Revolución! Unfortunately the host wasn't  
> ready for the job it volunteered for … we've put the poor thing out of  
> its misery.
>
> Thanks;
>    — Matt
>
> On Apr 17, 2009, at 09:01 AM, Matt Sanford wrote:
>
> > Hi all,
>
> >     We're not seeing the 403s in our normal logs but we've seen a  
> > few in responses. We're looking into the issue and I'll send out  
> > more info when I have it.
>
> > — Matt
>
> > On Apr 17, 2009, at 07:27 AM, Abraham Williams wrote:
>
> >> This seems to indicate it too.
>
> >> The 403 Forbidden HTTP status code indicates that the client was  
> >> able to communicate with the server, but the server doesn't let the  
> >> user access what was requested.
>
> >>http://en.wikipedia.org/wiki/HTTP_403
>
> >> On Fri, Apr 17, 2009 at 07:46, Ivan  wrote:
>
> >> Hi,
>
> >> Twitter returns a HTTP 403 if you make a properly authorized follow
> >> request to a user already followed.
>
> >> That seems like the wrong kind of response. It should return 200,  
> >> with
> >> data saying the friendship already existed, no?
>
> >> Ivan
> >>http://tipjoy.com
>
> >> --
> >> Abraham Williams |http://the.hackerconundrum.com
> >> Hacker |http://abrah.am|http://twitter.com/abraham
> >> Web608 | Community Evangelist |http://web608.org
> >> This email is: [ ] blogable [x] ask first [ ] private.
> >> Sent from Madison, Wisconsin, United States

[twitter-dev] Re: 403 on valid request to friendships/create/ if friendship already exists

[Matt Sanford]

Hi all,

The issue with random HTTP 403s on search (both API and web)  
should now be fixed. Similar to the employee password prompts a few  
days ago we had a host unexpectedly join the search cluster. We want  
more capacity so bad we're actually convincing inanimate objects to  
join our cause. ¡Viva La Revolución! Unfortunately the host wasn't  
ready for the job it volunteered for … we've put the poor thing out of  
its misery.


Thanks;
  — Matt

On Apr 17, 2009, at 09:01 AM, Matt Sanford wrote:


Hi all,

We're not seeing the 403s in our normal logs but we've seen a  
few in responses. We're looking into the issue and I'll send out  
more info when I have it.


— Matt

On Apr 17, 2009, at 07:27 AM, Abraham Williams wrote:


This seems to indicate it too.

The 403 Forbidden HTTP status code indicates that the client was  
able to communicate with the server, but the server doesn't let the  
user access what was requested.


http://en.wikipedia.org/wiki/HTTP_403

On Fri, Apr 17, 2009 at 07:46, Ivan  wrote:

Hi,

Twitter returns a HTTP 403 if you make a properly authorized follow
request to a user already followed.

That seems like the wrong kind of response. It should return 200,  
with

data saying the friendship already existed, no?

Ivan
http://tipjoy.com



--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Tweet Corpus creation for NLP research

[Nick Arnett]

On Fri, Apr 17, 2009 at 9:17 AM, djMax  wrote:

>
> http://drop.io
>

The free version is limited to 100MB...  I could split it, I guess.  Any
others with a higher limit?

Nick

[twitter-dev] Re: 403 on valid request to friendships/create/ if friendship already exists

[Ivan Kirigin]

This could also just be a bug in the python code I'm using - maybe
even something in urllib2 going wrong.

Here is a bit of my code for reference, a function which makes an HTTP
POST with a username & password. For an existing friendship, this will
throw an exception printed out as:

HTTP Error 403: Forbidden



import sys
import urllib2
import urlparse
import json
def twitter_post_pw(url, data, twitter_username, twitter_password):
encoded_data = twitter_encode(data)
realm = "Twitter API"
(scheme, netloc, path, params, query, fragment) = urlparse.urlparse
(url)
handler = urllib2.HTTPBasicAuthHandler()
handler.add_password(realm, netloc, twitter_username,
twitter_password)
opener = urllib2.build_opener(handler)
try:
o = opener.open(url, encoded_data)
return json.read( o.read() )
except:
for e in sys.exc_info():
print e
return False

def twitter_encode( data ):
return urllib.urlencode(dict([(k, unicode(v).encode('utf-8')) for
k, v in data.items()]))

On Apr 17, 12:01 pm, Matt Sanford  wrote:
> Hi all,
>
>      We're not seeing the 403s in our normal logs but we've seen a few  
> in responses. We're looking into the issue and I'll send out more info  
> when I have it.
>
> — Matt
>
> On Apr 17, 2009, at 07:27 AM, Abraham Williams wrote:
>
> > This seems to indicate it too.
>
> > The 403 Forbidden HTTP status code indicates that the client was  
> > able to communicate with the server, but the server doesn't let the  
> > user access what was requested.
>
> >http://en.wikipedia.org/wiki/HTTP_403
>
> > On Fri, Apr 17, 2009 at 07:46, Ivan  wrote:
>
> > Hi,
>
> > Twitter returns a HTTP 403 if you make a properly authorized follow
> > request to a user already followed.
>
> > That seems like the wrong kind of response. It should return 200, with
> > data saying the friendship already existed, no?
>
> > Ivan
> >http://tipjoy.com
>
> > --
> > Abraham Williams |http://the.hackerconundrum.com
> > Hacker |http://abrah.am|http://twitter.com/abraham
> > Web608 | Community Evangelist |http://web608.org
> > This email is: [ ] blogable [x] ask first [ ] private.
> > Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Tweet Corpus creation for NLP research

[djMax]

http://drop.io

On Apr 17, 12:07 pm, Nick Arnett  wrote:
> Michele, djMax and anybody else interested...  It is a 128MB file after
> gzipping (291MB uncompressed).  Any thoughts on a place to put it for
> download?  I'm reluctant to sacrifice a lot of my own bandwidth for this and
> off the top of my head, I can't think of a good place to share it.
> Nick

[twitter-dev] Re: Tweet Corpus creation for NLP research

[Nick Arnett]

Michele, djMax and anybody else interested...  It is a 128MB file after
gzipping (291MB uncompressed).  Any thoughts on a place to put it for
download?  I'm reluctant to sacrifice a lot of my own bandwidth for this and
off the top of my head, I can't think of a good place to share it.
Nick

[twitter-dev] Re: 403 on valid request to friendships/create/ if friendship already exists

[Matt Sanford]

Hi all,

We're not seeing the 403s in our normal logs but we've seen a few  
in responses. We're looking into the issue and I'll send out more info  
when I have it.


— Matt

On Apr 17, 2009, at 07:27 AM, Abraham Williams wrote:


This seems to indicate it too.

The 403 Forbidden HTTP status code indicates that the client was  
able to communicate with the server, but the server doesn't let the  
user access what was requested.


http://en.wikipedia.org/wiki/HTTP_403

On Fri, Apr 17, 2009 at 07:46, Ivan  wrote:

Hi,

Twitter returns a HTTP 403 if you make a properly authorized follow
request to a user already followed.

That seems like the wrong kind of response. It should return 200, with
data saying the friendship already existed, no?

Ivan
http://tipjoy.com



--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Getting Source Parameter in Java from XML returns "<"

[Steve Brunton]

On Thu, Apr 16, 2009 at 11:11 PM, Travis James
 wrote:
>
> Can anyone show me how I would parse this?
> I am not exactly sure how I would go about doing this. Here is the
> parsing code I have.
>

Why not just use the java-twitter API?

http://code.google.com/p/java-twitter/

-steve

[twitter-dev] Re: API - getting info about user is blocked

[Abraham Williams]

http://code.google.com/p/twitter-api/issues/detail?id=9

On Fri, Apr 17, 2009 at 09:59, kkapron  wrote:

>
> Hello,
>
> I'm developing a Twitter client application and I have a small
> problem.
>
> In the Twitter API are methods for blocking and unblocking users, but
> I can't use them in efficient way because it's missing the method for
> checikng if a user is blocked by "me" (authorized user).
>
> I haven't found any solution of this issue, so I'm writing here :)
>
> It will be very useful, to add such method.
>
> Kamil
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Getting HTTP 500 from statuses/followers using OAuth

[Dossy Shiobara]

I'm using the HTTP Authorization header to pass along the OAuth 
signature, and getting HTTP 500 errors back.


I know that the signature is correct, because if I intentionally perturb 
the Authorization header I'm sending with junk, I get HTTP 401 responses 
saying "Failed to validate oauth signature or token" instead.


Seriously, I'm the only one seeing this behavior?

--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Sign in with Twitter

[John Kristian]

It would be nice to support applications that merely authenticate,
never authorize.  That is, they don't ask for permission to access
Twitter on the user's behalf.  Such an application would never direct
a user to /oauth/authorize, and thus would never get a token secret
from the authorization flow.  Nonetheless, it might need a secure way
to get the user's ID and name.

On Apr 17, 1:02 am, Abraham Williams <4bra...@gmail.com> wrote:
> The oauth_token returned from oauth/authenticate is the key from the users
> access tokens. as long as you store the access tokens you can match the
> returned oauth_token with what is in your database.

[twitter-dev] Re: Fail Whale

[TweetPhoto]

Will do Doug, thanks a lot for your help.

Just to let you know, we're launching TweetPhoto on April 27th so our
volume of API requests/calls is going to sky rocket from current
levels.

Thanks you for the support and help!

Sean

On Apr 7, 8:44 am, Doug Williams  wrote:
> Ouch. When you start to see this behavior you can send an @reply to
> @twitterapi so I can check it out?
>
> Doug Williams
> Twitter API Supporthttp://twitter.com/dougw
>
>
>
> On Tue, Apr 7, 2009 at 5:04 AM, TweetPhoto  wrote:
>
> > I'm beginning to notice at high peak times throughout the day on
> > Twitter, users logging into a service through OAuth will receive a
> > Fail Whale message. It appears that services using the old Twitter
> > login method don't have a problem at these high peak times. I have
> > ideas about how to fix this. What are your thoughts?- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] API - getting info about user is blocked

[kkapron]

Hello,

I'm developing a Twitter client application and I have a small
problem.

In the Twitter API are methods for blocking and unblocking users, but
I can't use them in efficient way because it's missing the method for
checikng if a user is blocked by "me" (authorized user).

I haven't found any solution of this issue, so I'm writing here :)

It will be very useful, to add such method.

Kamil

[twitter-dev] Re: OAuth and screen name

[Matt Sanford]

Hello again,

Let me be more specific that my previous mails. This will be  
changing. Let me emphasize that:


⚠ The new authenticate method will be changing in a way that breaks  
the current behavior.


At this point it is only a matter of time until I can get the new  
code reviewed and deployed. I would suggest people hold off on the  
authenticate method for the moment. I'll send more details once the  
code is reviewed and we're sure it won't be delayed for some reason.


Thanks;
  — Matt Sanford

On Apr 17, 2009, at 06:26 AM, djMax wrote:



I believe this flow is not secure (or not "as" secure) because that
URL that is "transmitted" via the browser is permanently reusable by
anyone to login to my service as that twitter user.  In the
authorization flow, I don't believe any such URL ever goes through the
browser.

So basically I think the Twitter folks need to change the last step in
the flow to be an exchange of a request token to the original access
token by the app on the backend...

On Apr 17, 8:01 am, Dossy Shiobara  wrote:

On 4/17/09 2:51 AM, Abraham Williams wrote:


They correct flow is:
1) get request token from twitter.
2) send user to twitter with oauth_token for the first time.


Send the user to Twitter how, though?  oauth/authorize?  How do you  
know

if this is the user's first time or not?


3) user returns and app uses request token to get user access token
which get stored.


This is fine, unless the user returns with an access token and not  
the

original request token.  This is what currently happens with
oauth/authenticate.


4) user come back to site to sign in and is not signed in.
5) site gets request token from twitter.
6) user is sent to twitter with request oauth_token and are
automatically redirected back to site.
7) access oauth_token is returned with user which can be matched  
with

oauth_token_secret stored in the database.


This would work fine, assuming in step #2 you had some way of knowing
whether a Twitter user had never previously OAuth authorized your  
app.


--
Dossy Shiobara  | do...@panoptic.com |http://dossy.org/
Panoptic Computer Network   |http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth and screen name

[Abraham Williams]

On Fri, Apr 17, 2009 at 07:01, Dossy Shiobara  wrote:

>
> On 4/17/09 2:51 AM, Abraham Williams wrote:
>
>> They correct flow is:
>> 1) get request token from twitter.
>> 2) send user to twitter with oauth_token for the first time.
>>
>
> Send the user to Twitter how, though?  oauth/authorize?  How do you know if
> this is the user's first time or not?
>

Either/Or.


>
>
>  3) user returns and app uses request token to get user access token
>> which get stored.
>>
>
> This is fine, unless the user returns with an access token and not the
> original request token.  This is what currently happens with
> oauth/authenticate.
>

If they previously authorized and authenticate was used you would have to
check the beginning of the oauth_token string for the user_id.


>
>
>  4) user come back to site to sign in and is not signed in.
>> 5) site gets request token from twitter.
>> 6) user is sent to twitter with request oauth_token and are
>> automatically redirected back to site.
>> 7) access oauth_token is returned with user which can be matched with
>> oauth_token_secret stored in the database.
>>
>
> This would work fine, assuming in step #2 you had some way of knowing
> whether a Twitter user had never previously OAuth authorized your app.
>
> --
> Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
>
> Panoptic Computer Network   | http://panoptic.com/
>  "He realized the fastest way to change is to laugh at your own
>folly -- then you can let go and quickly move on." (p. 70)
>

-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: OAuth and screen name

[djMax]

I believe this flow is not secure (or not "as" secure) because that
URL that is "transmitted" via the browser is permanently reusable by
anyone to login to my service as that twitter user.  In the
authorization flow, I don't believe any such URL ever goes through the
browser.

So basically I think the Twitter folks need to change the last step in
the flow to be an exchange of a request token to the original access
token by the app on the backend...

On Apr 17, 8:01 am, Dossy Shiobara  wrote:
> On 4/17/09 2:51 AM, Abraham Williams wrote:
>
> > They correct flow is:
> > 1) get request token from twitter.
> > 2) send user to twitter with oauth_token for the first time.
>
> Send the user to Twitter how, though?  oauth/authorize?  How do you know
> if this is the user's first time or not?
>
> > 3) user returns and app uses request token to get user access token
> > which get stored.
>
> This is fine, unless the user returns with an access token and not the
> original request token.  This is what currently happens with
> oauth/authenticate.
>
> > 4) user come back to site to sign in and is not signed in.
> > 5) site gets request token from twitter.
> > 6) user is sent to twitter with request oauth_token and are
> > automatically redirected back to site.
> > 7) access oauth_token is returned with user which can be matched with
> > oauth_token_secret stored in the database.
>
> This would work fine, assuming in step #2 you had some way of knowing
> whether a Twitter user had never previously OAuth authorized your app.
>
> --
> Dossy Shiobara              | do...@panoptic.com |http://dossy.org/
> Panoptic Computer Network   |http://panoptic.com/
>    "He realized the fastest way to change is to laugh at your own
>      folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth Authentication - clarification needed

[djMax]

This thread is kind of a dupe of

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a27298269b429a15

I'd suggest we move the convo over there?  My last post in that thread
describes why I think the current flow is not secure, which is
essentially what Dossy says I think.  That last token passed from
Twitter to the app cannot simply be the original permanent token.

On Apr 17, 7:29 am, Dossy Shiobara  wrote:
> On 4/16/09 10:56 PM, Dimebrain wrote:
>
> > It should be no different than if you persisted the access token
> > yourself and went to call the API a few weeks after doing so, you
> > should be able to trust that your token won't expire.
>
> But this still leaves the question of "how do I get and/or know the
> token secret for the returned AccessToken" ... this is the current
> execution path:
>
> Consumer invokes oauth/request and receives a RequestToken and
> corresponding token secret.  Consumer directs user to oauth/authenticate
> with RequestToken.  Assuming user authenticates and authorizes the
> application, Provider directs user back to callback URL with an
> AccessToken.  Consumer now has a RequestToken and secret, and
> AccessToken without its secret.
>
> That AccessToken is effectively useless to the Consumer.
>
> --
> Dossy Shiobara              | do...@panoptic.com |http://dossy.org/
> Panoptic Computer Network   |http://panoptic.com/
>    "He realized the fastest way to change is to laugh at your own
>      folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: To link the @ or not to link the @, that is the question

[Abraham Williams]

I don't link the @ sign because 1) I don't like how it looks and 2)
Twitter.com does not.

On Fri, Apr 17, 2009 at 09:21, Chad Etzel  wrote:

>
> A more lighthearted discussion to see where people stand on this
> convention.
>
> We all know the convention of prefixing usernames with the @ symbol,
> the interesting thing I notice is that different sites (and even
> within tiwtter's site itself) decide to link or not link the @ symbol
> along with it.
>
> Main twitter site: is NOT linked
> search.twitter.com: IS linked
> new twitter integrated sidebar search: IS linked (i suppose this uses
> the same code as search.twitter)
>
> TweetGrid: is NOT linked
> Tweetie: IS linked
> etc..
>
> just curious how people decided which convention to use.
>
> From a visual perspective I prefer having the @ be plaintext since it
> provides a nice visual difference looking at word, whereas normal
> links are bounded by whitespace.  This makes the usernames pop out (to
> my eyes anyway).
>
> -Chad
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: 403 on valid request to friendships/create/ if friendship already exists

[Abraham Williams]

This seems to indicate it too.

The *403 Forbidden*
HTTP status
> code  indicates
> that the client was able to communicate with the server, but the server
> doesn't let the user access what was requested.


http://en.wikipedia.org/wiki/HTTP_403

On Fri, Apr 17, 2009 at 07:46, Ivan  wrote:

>
> Hi,
>
> Twitter returns a HTTP 403 if you make a properly authorized follow
> request to a user already followed.
>
> That seems like the wrong kind of response. It should return 200, with
> data saying the friendship already existed, no?
>
> Ivan
> http://tipjoy.com




-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] To link the @ or not to link the @, that is the question

[Chad Etzel]

A more lighthearted discussion to see where people stand on this convention.

We all know the convention of prefixing usernames with the @ symbol,
the interesting thing I notice is that different sites (and even
within tiwtter's site itself) decide to link or not link the @ symbol
along with it.

Main twitter site: is NOT linked
search.twitter.com: IS linked
new twitter integrated sidebar search: IS linked (i suppose this uses
the same code as search.twitter)

TweetGrid: is NOT linked
Tweetie: IS linked
etc..

just curious how people decided which convention to use.

>From a visual perspective I prefer having the @ be plaintext since it
provides a nice visual difference looking at word, whereas normal
links are bounded by whitespace.  This makes the usernames pop out (to
my eyes anyway).

-Chad

[twitter-dev] Re: OAuth Authentication - clarification needed

[Dimebrain]

I think the thinking is, the first time a user authenticates using our
app, we get the access token and it's up to us to persist the secret.
Then we can use the authenticate approach, get back the user's token
(it should be the same one we have), and then match it up to the
access token paired to it.

So, yeah I think this makes the scenario where you want a simple app
that uses cookies not plausible for the authenticate scheme. You're
better off running authorize each time for those, or at most, just
when you no longer have the secret in hand.

So Twitter as auth provider, not quite.

On Apr 17, 8:29 am, Dossy Shiobara  wrote:
> On 4/16/09 10:56 PM, Dimebrain wrote:
>
> > It should be no different than if you persisted the access token
> > yourself and went to call the API a few weeks after doing so, you
> > should be able to trust that your token won't expire.
>
> But this still leaves the question of "how do I get and/or know the
> token secret for the returned AccessToken" ... this is the current
> execution path:
>
> Consumer invokes oauth/request and receives a RequestToken and
> corresponding token secret.  Consumer directs user to oauth/authenticate
> with RequestToken.  Assuming user authenticates and authorizes the
> application, Provider directs user back to callback URL with an
> AccessToken.  Consumer now has a RequestToken and secret, and
> AccessToken without its secret.
>
> That AccessToken is effectively useless to the Consumer.
>
> --
> Dossy Shiobara              | do...@panoptic.com |http://dossy.org/
> Panoptic Computer Network   |http://panoptic.com/
>    "He realized the fastest way to change is to laugh at your own
>      folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Sign in with Twitter

[Matt Sanford]

Hi all,

This behavior (i.e. which token is returned) is likely to change  
soon. Once again, stay tuned for updates.


— Matt

On Apr 17, 2009, at 01:02 AM, Abraham Williams wrote:

The oauth_token returned from oauth/authenticate is the key from the  
users access tokens. as long as you store the access tokens you can  
match the returned oauth_token with what is in your database.


On Fri, Apr 17, 2009 at 01:35, John Kristian   
wrote:


I'm having trouble using /oauth/authenticate, too.  After
authenticating, Twitter redirects back to my consumer with a different
oauth_token than the one I sent to initiate authentication.  Twitter
APIs don't accept either token.  Sending the original request token
to /oauth/access_token elicits HTTP 401 with an XML error "Invalid /
expired Token".  Sending the second callback token elicits HTTP 500
Internal Server Error with an HTML body entitled "Twitter / Error".
When either token is used as an access token, Twitter responds with
401.  The original request token elicits an XML error "Invalid /
expired Token"; the second token elicits "Failed to validate oauth
signature or token".

For signing I used the token secret associated with the original
request token.  The user has already given permission to this
consumer.

Help?

On Apr 16, 12:25 pm, Dossy Shiobara  wrote:
> I just tried out the oauth/authenticate - I supplied a  
RequestToken and

> it redirected back to my callback URL with an AccessToken ... but,
> what's the token secret for this AccessToken?  I only know the  
secret
> for the RequestToken I sent it ... Is the token secret the same  
for the

> AccessToken I get back?



--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: update_profile_image api issues

[Matt Sanford]

Hi Raghu,

This issue [1] , like any other in Google Code can be 'starred'  
so you receive updates. Visit the issues in question [1], Sign in with  
your Google account, and then click on the star next to the title.  
When we update the issue you'll get an email.


Thanks;
  — Matt Sanford / @mzsanford

[1] - http://code.google.com/p/twitter-api/issues/detail?id=451

On Apr 16, 2009, at 10:52 PM, Raghu Prasad wrote:




On Apr 15, 6:10 pm, ctshryock  wrote:
I have an app that posts new profile images using  
update_profile_image

in the API.
as of about 3 some weeks ago (rough guess) the images uploaded are
coming up broken, though I'm still getting a success status.

I dug through this group and found a curl example for testing this  
API

feature:

curl -F 'ima...@path/to/image' -H 'Expect:' -u 
USERNAME:PASSWORDhttp://twitter.com/account/update_profile_image.xml

I ran that in the terminal and got a xml return that seemed to
indicate success, it showed me the same (or similar) out put as / 
users/

show/username.xml, with the exception that the new profile image I
used in the curl command is not represented, instead it's still the
previous image, but on twitter.com/home the image is broken.



I faced the same problem. It takes some time for the profile image to
appear along with the tweets. When last checked, it took about an
hour. This doesn't happen if you update your profile image via
twitter.com
website. It is a known issue and apparently someone is looking into
it.
It would be nice if we know when this could be fixed.

Raghu

[twitter-dev] Rate limit status's "remaining_hits" element scope

[Dimebrain]

I just realized I don't know whether the remaining_hits element
returned for /account/rate_limit_status is a static number from the
beginning of the current hour, or if it is the remaining hits on a
rolling sixty minute cycle. Does anyone know?

[twitter-dev] 403 on valid request to friendships/create/ if friendship already exists

[Ivan]

Hi,

Twitter returns a HTTP 403 if you make a properly authorized follow
request to a user already followed.

That seems like the wrong kind of response. It should return 200, with
data saying the friendship already existed, no?

Ivan
http://tipjoy.com

[twitter-dev] Re: OAuth and screen name

[Dossy Shiobara]

On 4/17/09 2:51 AM, Abraham Williams wrote:

They correct flow is:
1) get request token from twitter.
2) send user to twitter with oauth_token for the first time.


Send the user to Twitter how, though?  oauth/authorize?  How do you know 
if this is the user's first time or not?



3) user returns and app uses request token to get user access token
which get stored.


This is fine, unless the user returns with an access token and not the 
original request token.  This is what currently happens with 
oauth/authenticate.



4) user come back to site to sign in and is not signed in.
5) site gets request token from twitter.
6) user is sent to twitter with request oauth_token and are
automatically redirected back to site.
7) access oauth_token is returned with user which can be matched with
oauth_token_secret stored in the database.


This would work fine, assuming in step #2 you had some way of knowing 
whether a Twitter user had never previously OAuth authorized your app.


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth Authentication - clarification needed

[Dossy Shiobara]

On 4/16/09 10:56 PM, Dimebrain wrote:

It should be no different than if you persisted the access token
yourself and went to call the API a few weeks after doing so, you
should be able to trust that your token won't expire.


But this still leaves the question of "how do I get and/or know the 
token secret for the returned AccessToken" ... this is the current 
execution path:


Consumer invokes oauth/request and receives a RequestToken and 
corresponding token secret.  Consumer directs user to oauth/authenticate 
with RequestToken.  Assuming user authenticates and authorizes the 
application, Provider directs user back to callback URL with an 
AccessToken.  Consumer now has a RequestToken and secret, and 
AccessToken without its secret.


That AccessToken is effectively useless to the Consumer.


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: OAuth Authentication - clarification needed

[Dossy Shiobara]

On 4/16/09 9:46 PM, djMax wrote:

That's where I'm confused:what do I do next?  If I try to turn that
OAuth Token into an access token, it fails, assumedly because it
already is an auth token.


Right, the oauth/authenticate returns the user to your callback URL with 
an AccessToken, not the original RequestToken you sent to 
oauth/authenticate.  How is the OAuth consumer supposed to know the 
token secret for this returned AccessToken?


That's the problem I'm having, too, which is why I'm still using 
oauth/authorize instead of oauth/authenticate.


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Search API throwing 404's

[dean....@googlemail.com]

Hi,

I've experienced a few 404's on search.json this morning.

Sometimes works, sometimes doesn't can't seem to pinpoint any
particular pattern to it happening.

--
Leu

On Apr 17, 5:11 am, Chad Etzel  wrote:
> Just a quick update:
>
> The problem as popped up again. Doug is aware of this problem, and he
> says the servers are all stretched pretty thin (understandable).  Just
> curious if anyone else is seeing this as well?
>
> -Chad
>
> On Thu, Apr 16, 2009 at 11:30 PM, Chad Etzel  wrote:
> > Ok, dunno what was happening... I gave my server a swift kick with my
> > steel-toed boot and all seems well again... weird.
> > -Chad
>
> > On Thu, Apr 16, 2009 at 10:27 PM, Doug Williams  wrote:
> >> I just sent 200 queries through without seeing the 404. Are you still 
> >> seeing
> >> this?
>
> >> Doug Williams
> >> Twitter API Support
> >>http://twitter.com/dougw
>
> >> On Thu, Apr 16, 2009 at 6:32 PM, Chad Etzel  wrote:
>
> >>> Search is throwing 404's for search.json about every 7 or 8 requests...
>
> >>> 
> >>> 
> >>> 404 Not Found
> >>> 
> >>> Not Found
> >>> The requested URL /search.json was not found on this server.
> >>> 
>
> >>> Also got a "Forbidden" return when trying to connect to
> >>>http://search.twitter.com/about 10 minutes ago.
>
> >>> -Chad

[twitter-dev] Re: sending DM to all followers?

[Marco Kaiser]

2009/4/17 Nicole Simon 

> On Fri, Apr 17, 2009 at 12:04 AM, Jesse Stay  wrote:
>
>
>> How do I switch off receiving DMs?  I get DMs no matter what.  I can turn
>> off notifications, but not DMs.
>>
>
> Twitter really has not a lot of options. If you do not know how to do that,
> you obviously never looked.
>
> http://twitter.com/account/notifications
>

Uhm... I think you got this completely wrong, as Jesse already pointed out.
These settings only control offline notifications via SMS or Email, but they
don't make your account stop receiving DMs. It's just plain false what you
say here.


>
> May I ask what you do on the _developper_ list if you do not even know this
> much?
>

Hold on - this is an open group, for everyone to share with little or much
knowledge about the Twiter API. In fact, one of its main purposes is to give
beginners a chance to learn about twitter development. What kind of attitude
is it to say you shouldn't be on this list if you don't know about it. It's
not a closed circle of professionals, and even if it would be - Jesse would
definitely belong in here, as he is a long-time participant and very active
developer. I think no one wants to see such behavior here, it's a place to
discuss questions about twitter, and not to start flaming other group
members.


Marco

[twitter-dev] Re: multiple tokens for the same user/application

[Mario Menti]

On Thu, Apr 16, 2009 at 9:46 PM, Mario Menti  wrote:

> On Thu, Apr 16, 2009 at 8:17 PM, Doug Williams  wrote:
>
>> Marlo,
>> You should currently only have one working token per user per application.
>> There is an open issue [1] that will allow multiple tokens per user per
>> application.
>>
>> 1. http://code.google.com/p/twitter-api/issues/detail?id=372
>>
>
> Hi Doug - thanks for this.
>
> Strangely, and I just tested this again to make sure, I can update the same
> user's status, from the same application, using 2 different tokens - both
> status updates work.
>

... testing again this morning, using the older token indeed returns a 401.
Strange though that yesterday both tokens definitely worked?

[twitter-dev] Re: Sign in with Twitter

[Abraham Williams]

The oauth_token returned from oauth/authenticate is the key from the users
access tokens. as long as you store the access tokens you can match the
returned oauth_token with what is in your database.

On Fri, Apr 17, 2009 at 01:35, John Kristian  wrote:

>
> I'm having trouble using /oauth/authenticate, too.  After
> authenticating, Twitter redirects back to my consumer with a different
> oauth_token than the one I sent to initiate authentication.  Twitter
> APIs don't accept either token.  Sending the original request token
> to /oauth/access_token elicits HTTP 401 with an XML error "Invalid /
> expired Token".  Sending the second callback token elicits HTTP 500
> Internal Server Error with an HTML body entitled "Twitter / Error".
> When either token is used as an access token, Twitter responds with
> 401.  The original request token elicits an XML error "Invalid /
> expired Token"; the second token elicits "Failed to validate oauth
> signature or token".
>
> For signing I used the token secret associated with the original
> request token.  The user has already given permission to this
> consumer.
>
> Help?
>
> On Apr 16, 12:25 pm, Dossy Shiobara  wrote:
> > I just tried out the oauth/authenticate - I supplied a RequestToken and
> > it redirected back to my callback URL with an AccessToken ... but,
> > what's the token secret for this AccessToken?  I only know the secret
> > for the RequestToken I sent it ... Is the token secret the same for the
> > AccessToken I get back?
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: OAuth and screen name

[John Kristian]

It would make more sense to me, too, to use the same protocol flow for
oauth/authorize and /authenticate.

On Apr 16, 11:51 pm, Abraham Williams <4bra...@gmail.com> wrote:
> It seems like it would make more sense to use the same work flow for both
> oauth/authorize and oauth/authenticate. Then the same code could be used in
> the callback function and the authenticate method would be more secure.

[twitter-dev] Re: Sign in with Twitter

[John Kristian]

I'm having trouble using /oauth/authenticate, too.  After
authenticating, Twitter redirects back to my consumer with a different
oauth_token than the one I sent to initiate authentication.  Twitter
APIs don't accept either token.  Sending the original request token
to /oauth/access_token elicits HTTP 401 with an XML error "Invalid /
expired Token".  Sending the second callback token elicits HTTP 500
Internal Server Error with an HTML body entitled "Twitter / Error".
When either token is used as an access token, Twitter responds with
401.  The original request token elicits an XML error "Invalid /
expired Token"; the second token elicits "Failed to validate oauth
signature or token".

For signing I used the token secret associated with the original
request token.  The user has already given permission to this
consumer.

Help?

On Apr 16, 12:25 pm, Dossy Shiobara  wrote:
> I just tried out the oauth/authenticate - I supplied a RequestToken and
> it redirected back to my callback URL with an AccessToken ... but,
> what's the token secret for this AccessToken?  I only know the secret
> for the RequestToken I sent it ... Is the token secret the same for the
> AccessToken I get back?

[twitter-dev] Re: Sign in with Twitter

[John Kristian]

It just dawned on me: it looks like /oauth/authenticate is designed to
merely deliver a user's ID and screen_name to a application, not to
authorize the application to access Twitter on the user's behalf.  Is
that so?

A suggestion: treat the user ID and screen_name as a resource that's
protected by OAuth.  Define /oauth/authenticate as the place a user
authorizes an application to get the ID and screen_name.

So, the flow would go like this:
1. The application GETs a request token from /oauth/request_token.
2. The application redirects the user's browser to /oauth/
authenticate.
3. The user authenticates and/or gives permission, if needed.
4. Twitter redirects the browser to the application callback.
5. The application GETs an access token from /oauth/access_token.
6. The application GETs the user ID and screen name from /account/
verify_credentials or something similar.

No sensitive data are passed from Twitter via browser redirects to the
application.  The application may use HTTPS to secure its requests to
twitter.com/oauth.

On Apr 16, 11:48 am, Dossy Shiobara  wrote:
> On 4/16/09 2:33 PM, Matt Sanford wrote:
>
> > The initial token required is a RequestToken rather than an AccessToken.
> > Making the request for the RequestToken requires you know the consumer
> > key/secret and (a) let's us know what application this is for
> > (callback_url alone would not) and (b) prevent the token-shooting method
> > you described.
>
> How does this prevent (b)?  If I know a third-party application's
> callback URL, I can currently brute-force a user's oauth_token, assisted
> by a basic session-fixation attack.  The callback URL isn't signed by
> Twitter.
>
> Perhaps oauth/authenticate would require a signed request that doesn't
> include/require oauth_token.  Upon successful process flow, Twitter
> would send the user back using a signed callback URL that includes the
> user's oauth_token.  Then, all we would need is a method to retrieve the
> oauth_token_secret for that oauth_token.