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 <[email protected]> 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 <[email protected]> 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 | [email protected] |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)
