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
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!!

Reply via email to