Hey everyone, There has been some really great discussion and questions since the last set of answers. I've responded to the ones we seen since last night below.
> Can Read/Write applications send direct messages? Yes. Read/Write tokens can send direct messages using direct_messages/ new. The endpoints which will require the R/W/DM permission will be: - /1/direct_messages.{format} - /1/direct_messages/sent.{format} - /1/direct_messages/show.{format} - /1/direct_messages/destroy.{format} > I adjusted my application permissions but the OAuth login still shows no > permissions for direct messages. Should this change have been immediate? The permission level for your application can be edited on http://dev.twitter.com/apps. When the website is busy, it can take a little bit longer for changes to your application to be reflected. > Is using a web view against the Terms of Service (TOS)? Using an in-app web view to show the OAuth pages is not against our TOS. However, we encourage developers to use the built-in browser where appropriate. > You said you were restricting this permission to the OAuth /authorize web > flow only. Will /oauth/authenticate (Sign in with Twitter) support the new > permission? The R/W/DM permission can only be granted through the /oauth/authorize route. Sign in with Twitter cannot be used to grant R/W/DM. We understand applications may use other methods of authentication like Sign in with Twitter as well. For this reason, if a user has authorised your application for R/W/DM and you direct them through Sign in with Twitter, we will respect the existing access token permission. This means you can use Sign in with Twitter after a user has authorized your application for R/W/DM. > I’ve read that users will be asked to do this on every use of an application, > is that true? No, this is a misunderstanding. The way OAuth works hasn’t changed and users only need to authorize an application once. Remember we do not expire access tokens and the only time users have to reauthorize is when an application requests them to. > Wouldn't it be possible to keep the DM access rights with xAuth and only > revoke it upon user complaints or your monitoring of API usage? The reason for asking users to reauthorize is so they can make a more informed decision about the access an application has requested. There may be users of your application who are comfortable with the level of access you have requested, while there could be others who complain. By having the user re-authorize, they get to decide if they agree with the access your application has requested. > The way it's being taken in the news is that Twitter is doing this because > developers have been abusing their privacy. The new permission level has been added in response to user and developer requests for more clarity around the access an application has to an account. > I have not seen a method we can use to effectively test this besides changing > our code and waiting? When the new permission is enforced we will return an HTTP 403 Forbidden error with the response body: {"errors":[{"code":93,"message":"This application is not allowed to access or delete your direct messages"}]} > How do we know what the access level of a user token is? This is a great idea and one the team has discussed. What we are going to do is add a new header to authentication requests that will tell you the access level of the token you authenticated with. We’re working on this now and hope to have it released in the next few days. > We support multiple accounts in our application, how do we force a login on > the authorize flow? Currently the only flow that supports the force_login parameter is / oauth/authenticate but adding it to /oauth/authorize flow is a good idea. We’ll begin working on this now and will let you know when it is released. > Is there sample code we can use that shows the appropriate OAuth flow and how > to handle multiple users? This is a great idea and one which is best handled by our client teams. When they have some example code we’ll let you know. > How do I specify a custom callback URL? The website won’t let me. You can set the callback dynamically during the request_token phase of OAuth. To this you should register your application as browser based, and put a placeholder URL in the callback box. The placeholder URL should be something like the about page of your application. Custom callbacks can only be specified at runtime and cannot be registered as the default callback of an application. More information on the request_token method is provided on our developer resources site: http://dev.twitter.com/doc/post/oauth/request_token Be sure to include a path with your callback. For example: myapp://oauth_complete We're collating all these questions and answers on the developer resources site. If your email client doesn't render the responses above clearly please visit https://dev.twitter.com/pages/application-permission-model 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