If you're a developer who got bit in the ass by this move by Twitter, and need to migrate your application from using xAuth to using OAuth, I have a sample project which shows you how to obtain authorization for a user. It's Objective-C, but the concepts should be applicable to whatever language you're coding in. You can check it out at https://github.com/amazingsyco/oauthery.
Steve On May 18, 5:11 pm, themattharris <thematthar...@twitter.com> wrote: > Hey everyone, > > Thank you for all the feedback on the list, email and through Tweets. > We've been responding throughout the day to many of the Tweets but > wanted to group the questions together and respond here as well. > > > Two weeks is not enough time to implement a web OAuth flow and have the app > > approved. We need an extension. > > We’ve heard your feedback on this list, privately and through Tweets > about this. Based on this feedback we are going to extend the > enforcement deadline by two weeks. > > **** This means we'll enforce the new permission the week beginning > the 14th June 2011. **** > > This should provide enough time for you to make the change and have > your application approved by your chosen platform’s app store. > > > Will Twitter's own applications also go through the OAuth web flow? > > We’re taking this step to give more clarity and control to users about > the access a third-party application has to their account. The way > users interact with Twitter’s clients is not expected to change. > > Applications who wish to access a user’s DMs will need to update their > application permission and incorporate the OAuth web flow if they > don’t already. If an application does not need access to DMs it will > not need to make any changes. > > > Why will you not grandfather existing applications into DM access? > > Grandfathering all existing read/write tokens assumes they all wanted > access to DMs. The feedback we’ve had from users and developers tells > us otherwise. We want to give users the opportunity to make an > informed choice. > > > What if the client using xAuth has no browser and therefore cannot go > > through OAuth? > > For single user applications and scripts we provide the 'My Access > Token' page of the application details. To ensure the 'My Access > Token' is correct it is important the app owner revokes their access > before change the permission level of the app. If you do not do this, > the 'My Access Token' will not be regenerated with the new permission. > This revoke action is only needed by you, the owner of the > application. Remember Read/Write applications can still send direct > messages. > > > When you activate the new permission, will all Read and Read/Write > > user_tokens issued to third-party applications lose their ability to read > > direct messages? > > Existing tokens are unaffected by any change to the application > permission level. If you change your application to R/W/DM all future > authorizations will be for that permission. When a user re-authorizes, > their existing token will be updated to the current application > permission level. Access to DMs will be enforced on 14th June 2011 if > the user_token wasn't authorised as for R/W/DM. > > > What if I want to request a different level of access for my application > > instead of the one my application is registered with? > > You can do this now by using the x_auth_access_type parameter during > the request_token phase. Using this parameter you can request a read > or a read/write token even if your application is registered for read/ > write/direct messages. > > More information on this method is in our developer documentation: > http://dev.twitter.com/doc/post/oauth/request_token > > > Why are permissions attached to the user token? > > Permissions are attached to the user token to ensure an application > only has the access a user has authorised. If permissions were not > attached to the user token an application would be able to change the > level of access they have without the user’s knowledge. If you tie the > permissions to the application each user token would need to be > invalidated whenever an application’s permissions are changed. > > > Users already gave their permission for apps to access private messages, > > why are you making us, and them, reauthorize? > > The purpose of the re-authorization is to ensure both users and > developers know the level of access requested. Re-authorization allows > a user to make a more informed decision about the access an > application has requested. > > We hope these responses answer your questions. Please continue to send > us your feedback about the permission model and what you would like to > see it offer. > > Best, > @themattharris -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
