On Mon, 24 Aug 2009 03:04:52 -0700 (PDT)
abhishek sanoujam <abhi.sanou...@gmail.com> wrote:

> You don't need to get permission everytime from the user if you are
> going to store it in a DB. The problem with this is that you will have
> to implement another level of authorization in your site/app, kind of
> a password for your app, so that when the session times out, or a user
> comes back again, he can authorize with your site's password and thus
> you can use the initial access token granted behind the scenes.

Right, you need your own session management. That can be anything from
HTTP Auth to cookies to your own User Database and the authentication 
routines native to your scripting language or framework.

> This way of doing things is against the "Sign in with Twitter"
> philosophy, but then I also don't see a way of re-using the access
> token if you are going with "Sign in with Twitter" philosophy. You are
> going to ask the user everytime (which means a If you use a cookie,
> or HTTP Basic Auth with anonymous users.new access token),

Sign in with Twitter isn't conceptually compatible with the design of
OAuth authentication, but it makes an attempt to deliver on what the
consumer expects from it. OAuth authentication allows the Consumer App
to use the Service Provider in the place of the user without knowledge
of the user name or password. It serves those authentication needs, but
as you see it doesn't meet some of the other expectations.

That some of these expectations are faulty, isn't of concern to our
users, nor should we necessarily expect the service provider to bear
the full brunt of building the bridge between the spec and the
expectation. Otherwise, what are you getting paid for? :-)

> and after getting a new access token, you are going to do
> verifyCredentials (to find out who logged in actually)... 

Everyone assumes that this is something they need to know and that the
verify credentials is the only way to find that out. Both assumptions
are false, at least as far as the functionality provided by the Twitter
API.

You don't need to know the user name to use OAuth. Access to API
methods using OAuth is as agnostic of usernames as it is passwords.

If you do need to know the user name then verify credentials is the
easiest and most obvious, but not the best, way to get it.

> and verify-
> credentials is limited to only 15 requests per 1 hour. This seems like
> using "Sign in with Twitter" and not reusing access token, you can
> login only 15 times in an hour? I hope this is not correct... but thts
> what I understand from
> http://apiwiki.twitter.com/Twitter-REST-API-Method:-account%C2%A0verify_credentials...
> If my assumptions are correct, 15 wrong verify-credentials requests
> from your site will halt your site for at least 1 hour .. and another
> 15 wrong requests for another 1 hour... which seems too easy for your
> competitors to block your app!! I'd rather add another authorization
> level in my app than face this...

No, you get 15 verify credentials requests per user regardless of
correctness or source. Since OAuth does not know the user, you may get
unlimited rejections but only 15 confirmations - shared with all other
apps regardless of their authentication method. That is why you can't
rely on it.

Instead, use http://twitter.com/statuses/user_timeline.xml?count=1 if
obtaining the user name is critical. If you are using Twitter accounts
to authenticate users on your site for non-Twitter services then
remember that screen names can change. Use the user_id instead.

Chris Babcock

Reply via email to