|
|
Twitter Development Talk |
On 4/16/09 12:55 PM, Doug Williams wrote: > Let's use this thread to fill the holes people find while implementing Are we supposed to request and use a new unauthorized token every time Also, the redirect to the callback URL has no signature. What stops an What would be ideal is a method that we can link a user to that follows Then, another method like oauth/token where a signed request with the Possible? --
> Related: More OAuth documentation is to come throughout the day so One issue I have is that the oauth/authenticate method expects an
> some of the links will be broken. It's a glaring omission in the
> documentation.
> Sign in with Twitter for the time being.
oauth_token as part of the request. Until we've authenticated the user,
how do we _know_ what the user's oauth_token should be?
we present the "sign in with Twitter" button in our third-party
application? (You can smell why this idea stinks, right?)
attacker from brute-force attacking an OAuth consumer, iterating through
posisble tokens? Simply the large search space of valid OAuth tokens?
Even if it's only "possible in theory" ... some teenager with nothing
better to do is going to eventually turn that theory into practice.
the oauth/authenticate 4-step decision tree described on the wiki but
requires only a callback URL. When Twitter sends the user back via the
callback URL, it should include a valid OAuth access token, Twitter user
ID and screen name, and signature.
OAuth token can be made that returns the token secret.
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)