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

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?

Reply via email to