Currently access tokens do not expire. You get same access token for a user sending request via particular consumer. Limit is per account not ip.
On Mon, Aug 24, 2009 at 3:34 PM, 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. > 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 new access token), and > after getting a new access token, you are going to do > verifyCredentials (to find out who logged in actually)... 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... > > corrections please!! >