Upgrading app permissions to read and write causes error (code 32) on calls with existing auth tokens that have read-only permissions

aliciatweet · 2012-11-12T19:43:59.000Z

Our app previously requested read-only permissions, and we changed it to read and write permissions. It is our understanding that the permission change should be seamless, and all of our previous auth tokens should still work for calls that only require read permissions. However, we are seeing them error with {“errors”:[{“message”:“Could not authenticate you”,“code”:32}]}

It appears we would need to immediately force all users to re-auth under the new permissions, which is not desirable behavior for us. Currently we have reverted the permissions back to read-only to stop the errors.

Is this a bug or intended behavior? In either case, we are looking for a workaround so we don’t need to force every user to re-auth until they actually need to do something that requires write permissions.

episod · 2012-11-13T16:04:03.000Z

Are you seeing this for all users who had read-only permissions previously or are you just seeing this for read-only tokens being used by a user who has upgraded to read-write permissions? The strings that represent access tokens change when a user upgrades their access level and any already existing tokens are invalidated. The part of your user base that hasn’t upgraded tokens yet should still be able to use their old tokens with impunity until they go through the access upgrade process.

aliciatweet · 2012-11-14T20:20:00.000Z

We have been able to narrow the problem down. It appears that all of our users that authenticated with Twitter through reverseAuth on iOS are failing, and in fact after we reverted the permissions back to read-only, these calls are all still failing.

It appears that changing permissions on an app that uses reverseAuth probably requires some kind of additional verification from Twitter. Do we need to submit another form?