Making calls to protected methods like direct_messages will fail if the
token is no longer valid. It is also possible that the test method will fail
with incorrect authentication info/oauth token. I have not tried it though.
Abraham

On Wed, Jul 22, 2009 at 03:10, Goblin <stu...@abovetheinternet.org> wrote:

>
> I've been updating my site to use OAuth and have found this to be a
> big problem. Without the ability to call verify_credentials I haven’t
> found a reliable way to ensure that logged in users with a valid
> session are still authorised with Twitter. It's unlikely they will
> revoke access in the middle of using the site, but the potential is
> there for an action to fail because of this. With verify_credentials I
> am able to check their OAuth tokens are still valid and also make sure
> their profile info is up to date. Spent several hours having a
> headache over this, especially since the API says these calls are
> unlimited. I was looking all over for unescaped loops and all sorts :)
>
> Agree that either making OAuth calls unlimited (since there shouldn't
> be a security vulnerability there) or making valid calls unlimited
> (same reason) whilst limiting invalid calls makes the most sense. As
> you say, you're still getting the security you want but without
> penalising legitimate users. If this is going to be a quick fix/
> rollback, I'll go back to using the method and deal with the low limit
> when testing for this week.
>
> Stuart
>
> On Jul 22, 6:49 am, Jesse Stay <jesses...@gmail.com> wrote:
> > Josh, is there a way, without verify_credentials, to identify that users
> > have changed their Twitter passwords (and therefore you are no longer
> able
> > to authenticate for them)?  For client apps, I don't see this being as
> much
> > of a problem, but for server-based apps that run regular scripts on
> behalf
> > of users this could become a regular issue, which is why we were running
> it.
> > In addition, what is the best way with OAuth to identify the screen name
> of
> > an individual?  verify_credentials is the only way I'm aware of, unless
> > there's something I'm missing (which is probably very likely).  I'd love
> to
> > know if there's a better way.  A best practices doc on how to retrieve
> user
> > information, and how to best verify users have not changed their
> passwords
> > would certainly be useful I think.  I'd like to know how Twitter
> recommends
> > we do this.
> >
> > Jesse
> >
> >
> >
> > On Tue, Jul 21, 2009 at 8:50 PM, Josh Perry <j...@6bit.com> wrote:
> >
> > > To be honest ever since the x-rate-limit HTTP headers were added we
> > > removed the call to verify_credentials from our Twitter API layer.
> >
> > > Every time that our Twitter API layer does an HTTP request it
> > > squirrels away the header values and any requests to our API from the
> > > application for rate-limit information is just fulfilled from those
> > > saved variables. So we don't need verify_credentials for rate-limit
> > > information
> >
> > > Every time that our API does an HTTP request it watches for
> > > unauthorized HTTP responses, so we don't need verify_credentials to
> > > verify that our app is still authorized on the account or that the
> > > user's password is still the same.
> >
> > > Every single twitter API method could be used to brute-force by
> > > sending HTTP auth headers and watching the HTTP response, but you are
> > > rate-limited to 150 requests/hour/ip, if this rate-limit is good
> > > enough for all the other attack vectors it should probably be good
> > > enough for verify_credentials. In fact verify_credentials is basically
> > > a nop function, which IMHO really isn't needed any longer.
> >
> > > Josh
> >
> > > On Jul 21, 7:00 pm, Doug Williams <d...@twitter.com> wrote:
> > > > Devs --A change shipped last week that limited the number of times a
> user
> > > > could access the account/verify_credentials method [1] in a given
> hour.
> > > This
> > > > change proved hasty and short-sighted as pointed out by the
> subsequent
> > > > discussion [2]. We apologize to any developer that was adversely
> > > > affected. Given the problems, we want to fix this in a
> > > > public and transparent manner.
> > > > Like most web services, we limit the number of attempts users can
> make to
> > > > login to
> > > > their accounts on Twitter.com to prevent brute force dictionary
> > > > attacks. This same security is not extended to the platform
> > > > and leaves accounts vulnerable to the same method of attack through
> the
> > > API.
> >
> > > > The change we shipped to limit user accounts to 15 calls an hour to
> the
> > > > account/verify_credentials method [1] was intended to mitigate this
> risk.
> > > It
> > > > was thought to limit the number of tests a potential attack could run
> in
> > > the
> > > > hour, even in a distributed fashion. However, we only protected a
> single
> > > > resource which still leaves all other authenticated methods exposed
> as a
> > > > vector of attack (limited only by the API rate limit).
> >
> > > > Our thinking is now that we will limit the total number of
> unsuccessful
> > > > attempts to access authenticated resources to 15 an hour per user per
> IP
> > > > address. If a single IP address makes 15 attempts to access a
> protected
> > > > resource unsuccessfully for a given user (as indicated by an HTTP
> 401),
> > > then
> > > > the user will be locked out of authenticated resources from that IP
> > > address
> > > > for 1 hour.
> >
> > > > This scheme has all of the positive effects that we need, however we
> want
> > > to
> > > > make sure that we have thought through all of the potential problems
> on
> > > the
> > > > developer's side before we proceed with this change. Please
> contribute to
> > > > the subsequent discussion if you have an opinion or concern. Once we
> come
> > > to
> > > > an agreement, we will update with details and a timeline for shipping
> > > this
> > > > update.
> >
> > > > 1.
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0ve.
> > > ..
> > > > 2.
> http://groups.google.com/group/twitter-development-talk/browse_thread.
> > > ..
> >
> > > > Regards,
> > > > Doug
>



-- 
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, WI, United States

Reply via email to