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
