Our implementation here is less than optimal at the moment during the
transition from basic auth to OAuth.

At least as it currently stands, you should think of API methods that
"require authentication" to mean "requires an access token" with OAuth. In
Basic Auth, it meant that you needed to provide a user and password with the
request.

If the API method "doesn't require authentication" that means that you don't
need an access token to complete the request.

Today, Twitter doesn't support two-legged OAuth, which would be the means
that your application could identify itself to Twitter and make requests
without an access token. This would be the most appropriate way for Twitter
to handle calls that are essentially consumer-to-service-provider without a
user.

Without two-legged OAuth support at Twitter yet, your best bet might be to
not use authentication at all when accessing resources that don't require
auth -- meaning, you just do simple REST calls without identifying yourself
with any OAuth parameters, basic auth, or otherwise (though a User-Agent is
always appreciated). Your requests would then be applied to the general
whitelist yielded solely to a requesting IP address.

Long-term, the right thing for Twitter to do here is support two-legged
OAuth. When your application is doing something that doesn't involve a user
in some way, you'd sign your requests and identify yourself as your
application while accessing the resource, but would not be supplying an
access token. In this scenario, all API requests, whether they require
authentication by a member or not, would require application-level
authorization.

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod


On Thu, May 20, 2010 at 1:20 AM, ALSPL <ritikasan...@gmail.com> wrote:

> Our app authenticates users with Twitter (using oAuth) and then sends
> API calls like
> 1. users show
> 2. status friends
>
> These calls do NOT require authentication but we want them to count
> against user's limit --> so it goes to 150/hr on users quota and NOT
> the app quota.
>
> However, even after making sure that the user is authenticated, these
> are not deducting the user's limit.
> curl -u user:password
> http://api.twitter.com/1/account/rate_limit_status.xml
> gives the same number - it does not get deducted.
>
> It seems that they are still getting counted in the app quota of 150/
> hr.
>
> Q1. How do we check if the app quota is getting deducted?
> Q2. How do we create/make the api calls so that they count against the
> user's quota?
>
> Thanks
>

Reply via email to