I recommend switching to OAuth where verify_credentials seems to be handled in conjunction with the oauth tokens rather than user/pass.
Here's how I use it: 1. User authorizes for the first time 2. Twitter user ID, Screen name, password (and various style data) is stored in my 'twitter_users' table >From that point on, when the user authorizes in the future each field is compared to the cached values in the database. If any are different.. the twitter_users table is updated with up to date info. It's always best to use twitter user id as an identifier rather than username. I suggest checking to see if <id> matches your stored ID each time a user logs in. If it's different (username has been reset and used by a new account) create a new row. Hope this helped in any way -Sam @sampicli http://twicli.com On Aug 15, 10:18 pm, "stasisme...@googlemail.com" <stasisme...@googlemail.com> wrote: > Hi all, > > I came across a strange issue today with a few users in my app that > still uses basic auth: > > 1. User signs up to app with username / password > 2. App verifies against verify_credentials > 3. On success, the returned <id> is stored. > > 4. User changes their screen_name, and that screen name is released to > be used by others > 5. User creates a new account, and uses the old username with same > password > 6. App continues to authenticate using username / password > > At thsi point, my app was processing the direct messages feed, and I > performed a 'just in case' check on the recipient_id and the stored > user_id. That's when some exceptions occurred, where the stored > user_id did not match the recipient_id. > > So I'm wondering - how have people protected against this?
