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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
