Question on xAuth

[im43232]

I’m designing a “Twitter Proxy Web Service” for our organization’s various public facing web sites. The purpose of the service is to get around with the rate limit of twitter rest api. Client web sites uses a modified twitter widget to obtain json from my service instead of twitter. My service serves as proxy/caching engine. I would like my service get data from twitter via authenticated request. Since number of client web sites is unknown, I cannot obtain a fixed number of access token in advance from dev.twitter.com. The only feasible oAuth option is xAuth. To that end I have a couple questions:

1. Does the access token generated by xAuth allow me to access REST api (same type of GET requests used by twitter widget)? the xAuth doc mentioned Direct message, which I’m not sure about.
2. If I perform xAuth multiple times (sending multiple POST requests) with same x_auth_username, does it generate different access tokens? Since rate limit on Rest API is imposed on access token, this is important to me. Ideally I want either every client web site or cached entry in my service using a unique access token.
3. If 2. is negative, then does xAuth yield different access token for different x_auth_username?

[episod]

xAuth will not likely be offered to you as an option since you’re capable of leveraging the web to do callback authorization.

Keys generated by OAuth or xAuth generally remain the same strings unless a permission has changed or the key has been explicitly revoked. Even so, you shouldn’t rely on that.

There’s no reason to perform xAuth (or OAuth) again, after you’ve obtained the access token and it remains valid.

Building a proxy just to get around rate limiting isn’t wise. If that’s what you’re trying to do, there’s likely another solution you haven’t thought of. What are you really trying to accomplish? What kind of API calls are you making and who are they on behalf of?

Some people on large internal networks leverage a caching proxy server like Squid such that your internal network folks hit your squid representation of an API URL – if it’s been x minutes since the last time it made the request, Squid will fetch the content and respond with it. If it’s been less than that, Squid would serve a cached version of the content. In this way you don’t worry about auth quite the same way.

[im43232]

The motivation behind this Twitter proxy service is to eliminate the possibility web site users from a large org sharing same public ip address get affected by the rate limit. It’s not a valid assumption that every large internal network has a proxy server. Even if it has, the proxy server may not be helpful because people may visit other sites embedded with Twitter widget which also count towards rate limit.
The API calls my proxy service will use are the same as Twitter javascript profile/list widget http://twitter.com/about/resources/widgets/widget_profile/.
Since authentication is performed at our server end, it is browerless therefore I cannot leverage other interactive web based authentication methods. The end user doesn’t require any authentication, just as Twitter javascript widget does.

[episod]

To achieve this without a proxy you won’t need xAuth really – just create a single access token and leverage it for all your requests from your proxy service and engineer it such that you’ll never make more than 350 requests per hour.

Also, just because your ultimate goal application is headless and won’t leverage a web browser doesn’t mean that you can’t create a side application (or reuse other people’s such side applications) to negotiate an access token internally which you would then use within your backend service. You can also leverage out-of-band OAuth for this purpose as well.

[im43232]

A single access token, or any fixed number of access tokens, cannot work no matter how I engineer it because the number of web sites/pages/widgets that my service serves is unknown. For example, if there are 400 widgets, all on popular sites and each pulls a different feeds using my service, then even if I cache each feed for 1hr is not adequate if I have only one access token.
Essentially what I need is being able to obtain a dynamic number of unique tokens without human intervention. By human intervention I mean either asking end user for login/approval (3-legged oAuth I guess) or developer acquiring access tokens from dev.twitter.com in advance. I thought the only feasible solution is through xAuth since it can pass user name/password in exchange for an access token dynamically.