ここで記載されていない質問がある場合は、 開発者メーリングリストから我々に教えてください。
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.
This means we’ll enforce the new permission on the 30th 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.
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.
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.
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.
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.
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/oauth/reference/post/oauth/request_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.
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.
Yes. Read/Write tokens can send direct messages using direct_messages/new.
The endpoints which will require the R/W/DM permission will be:
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.
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.
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.
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.
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 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.
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"}]}
For all authenticated API requests, we’re returning the “X-Access-Level” header that tells you what access level the user token you’re using has:
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.
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/oauth/reference/post/oauth/request_token
Be sure to include a path with your callback. For example: myapp://oauth_complete
You will need to negotiate an access token using the web-based OAuth flow to access direct messages in native iOS5 integrations using TWRequest.