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 <m...@twitter.com> 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 <do...@panoptic.com> 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)
