[twitter-dev] Re: OAuth and screen name
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
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: OAuth and screen name
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: OAuth and screen name
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
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
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
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: OAuth and screen name
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: OAuth and screen name
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: OAuth and screen name
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
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
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
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
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: OAuth and screen name
So my testing before was wrong somehow. I think I was not setting a callback url and was getting sent to production where I had a valid session already going. They correct flow is: 1) get request token from twitter. 2) send user to twitter with oauth_token for the first time. 3) user returns and app uses request token to get user access token which get stored. 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. 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. Sorry about all the misinformation. Abraham On Thu, Apr 16, 2009 at 17:25, djMax wrote: > > I'm not sure you don't have the secret for it. I'm still trying to > understand the tweet# code, but you were supposed to have saved the > "new" secret for that token when you got the original request token > right? Right now when trying to exchange that secondary oauth_token > for an access token, tweet# isn't passing a secret. > > On Apr 16, 6:14 pm, Dossy Shiobara wrote: > > On 4/16/09 6:02 PM, Abraham Williams wrote: > > > > > the oauth_token you are returned is only good for getting an access > > > token from oauth/access_token. that access token is what lets you act > as > > > the user. > > > > Wait, what? The oauth_token that's returned from the > > _oauth/authenticate_ method is already an Access Token, for which you > > don't have the secret to. > > > > I'm hoping Twitter fixes this somehow. > > > > -- > > 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
I'm not sure you don't have the secret for it. I'm still trying to understand the tweet# code, but you were supposed to have saved the "new" secret for that token when you got the original request token right? Right now when trying to exchange that secondary oauth_token for an access token, tweet# isn't passing a secret. On Apr 16, 6:14 pm, Dossy Shiobara wrote: > On 4/16/09 6:02 PM, Abraham Williams wrote: > > > the oauth_token you are returned is only good for getting an access > > token from oauth/access_token. that access token is what lets you act as > > the user. > > Wait, what? The oauth_token that's returned from the > _oauth/authenticate_ method is already an Access Token, for which you > don't have the secret to. > > I'm hoping Twitter fixes this somehow. > > -- > 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
I actually miss read djMix and just saw "authorize" and not "authenticate". That being said when I was testing oauth/authenticate a few days ago I used the *exact* same code for both oauth/authorize and oauth/authenticate and both worked implying a return of a request token. It is possible that I was not paying attention and was using access tokens from an older session though. I'll double check later tonight. Abraham On Thu, Apr 16, 2009 at 17:14, Dossy Shiobara wrote: > > On 4/16/09 6:02 PM, Abraham Williams wrote: > >> the oauth_token you are returned is only good for getting an access >> token from oauth/access_token. that access token is what lets you act as >> the user. >> > > Wait, what? The oauth_token that's returned from the _oauth/authenticate_ > method is already an Access Token, for which you don't have the secret to. > > I'm hoping Twitter fixes this somehow. > > > -- > 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
On 4/16/09 6:02 PM, Abraham Williams wrote: the oauth_token you are returned is only good for getting an access token from oauth/access_token. that access token is what lets you act as the user. Wait, what? The oauth_token that's returned from the _oauth/authenticate_ method is already an Access Token, for which you don't have the secret to. I'm hoping Twitter fixes this somehow. -- 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
the oauth_token you are returned is only good for getting an access token from oauth/access_token. that access token is what lets you act as the user. On Thu, Apr 16, 2009 at 16:36, djMax wrote: > > Ok got it. This explains more. So when I call authenticate (rather > than authorize) I get back the original oauth_token I was given in > authorize. The thing I'm not getting is how is this authenticated? > Anybody could find this token somewhere and then just become the user > in question right? > > On Apr 16, 5:32 pm, Matt Sanford wrote: > > Hi there, > > > > I recommend calling verify_credentials with your new token to > > verify the user in question. The screen_name was added as a > > convenience method because there were a great many complaints about > > have to do yet another round trip for the screen_name. > > > > Thanks; > >— Matt Sanford > > > > On Apr 16, 2009, at 02:11 PM, djMax wrote: > > > > > > > > > Sorry if this is a noob question, but how can we verify the > > > screen_name of an OAuth token? It would seem that having it only out > > > of band as a query arg means it's subject to spoofing right? Not sure > > > how I build secure site login with the core identifier may not match > > > the token I'm given. > -- 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
Ok got it. This explains more. So when I call authenticate (rather than authorize) I get back the original oauth_token I was given in authorize. The thing I'm not getting is how is this authenticated? Anybody could find this token somewhere and then just become the user in question right? On Apr 16, 5:32 pm, Matt Sanford wrote: > Hi there, > > I recommend calling verify_credentials with your new token to > verify the user in question. The screen_name was added as a > convenience method because there were a great many complaints about > have to do yet another round trip for the screen_name. > > Thanks; > — Matt Sanford > > On Apr 16, 2009, at 02:11 PM, djMax wrote: > > > > > Sorry if this is a noob question, but how can we verify the > > screen_name of an OAuth token? It would seem that having it only out > > of band as a query arg means it's subject to spoofing right? Not sure > > how I build secure site login with the core identifier may not match > > the token I'm given.
[twitter-dev] Re: OAuth and screen name
On 4/16/09 5:11 PM, djMax wrote: Sorry if this is a noob question, but how can we verify the screen_name of an OAuth token? It would seem that having it only out of band as a query arg means it's subject to spoofing right? Not sure how I build secure site login with the core identifier may not match the token I'm given. Right, that's why I keep saying that the callback URL needs to be signed ... so the consumer can protect against tampering of the request. -- 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
Hi there, I recommend calling verify_credentials with your new token to verify the user in question. The screen_name was added as a convenience method because there were a great many complaints about have to do yet another round trip for the screen_name. Thanks; — Matt Sanford On Apr 16, 2009, at 02:11 PM, djMax wrote: Sorry if this is a noob question, but how can we verify the screen_name of an OAuth token? It would seem that having it only out of band as a query arg means it's subject to spoofing right? Not sure how I build secure site login with the core identifier may not match the token I'm given.
