Hi,
We are building an application client that is browser based. We're
very comfortable with using OAuth from our server side code and are
using it fine with the REST API (users sign in, authenticate with
Twitter, we store their access tokens and reuse as requested - at the
moment we mimic the
OAuth 1.0a was made for server to server authentication. It uses secrets
for the client, which would make your application vulnerable. So, no,
you should not use JavaScript for OAuth. Not before Twitter starts using
OAuth 2.0.
About the document you are referring to: there are three types of
There would be one more issue which requires mentioning: JavaScript's
Same-origin policy. You can't make a request directly to the Twitter
API via JavaScript: you *will* need a proxy on your own server.
Which seems to put web developers at a sever disadvantage for search and
streaming APIs
I will indeed correct you: rate limits are based on account when using oauth.
Tom
On Oct 6, 2010, at 11:39 PM, Matthew Terenzio mteren...@gmail.com wrote:
There would be one more issue which requires mentioning: JavaScript's
Same-origin policy. You can't make a request directly to the
On Wed, Oct 6, 2010 at 5:48 PM, Tom van der Woerdt i...@tvdw.eu wrote:
I will indeed correct you: rate limits are based on account when using
oauth.
Really? Can someone second that. I re-read the documentation and it doesn't
look like it to me. Are the IP limits ignored when you log in as a
All the information about rate limits can be found on our developer site:
http://dev.twitter.com/pages/rate-limiting
When talking about rate limits it is important to be clear about the
API being used, as each has their own.
For the REST API (requests to api.twitter.com) the limit is 150
So yes, I was correct (at least with search) that a web based solution is
severely limited compared to a desktop. It will share usage among all it's
users while a desktop client can spread the load amongst its users IPs. That
stinks in my opinion. (I'm a web developer.)
On Wed, Oct 6, 2010 at
Well remember with Search you don't need to proxy from your server -
instead the Search API supports JSONP so you can run it directly from
the website.
Regarding Toms proxy comment. I think Tom was suggesting it for the
userstreams functionality. As userstreams require a long poll
connection
Fair enough.
On Wed, Oct 6, 2010 at 8:39 PM, Matt Harris thematthar...@twitter.comwrote:
Well remember with Search you don't need to proxy from your server -
instead the Search API supports JSONP so you can run it directly from
the website.
Regarding Toms proxy comment. I think Tom was
