> 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"}]}
The format of the error message differs from the one described in the following page.
I'm hoping it to be consistent.
> Hey everyone,
> We wanted to say a big thank you to the developers who have been sending us debug information, and details of steps to follow to reproduce device specific issues. An especially big thank you to those of you who have shared the changes you made to your applications on the mailing list.
> All of this information has helped us to improve the OAuth flow for you and your users. But, we know that we're getting close to the DM enforcement date and that some of these new features aren't available to you yet.
> We understand this means you might not be able to fully test your updated flow so we are going to extend the deadline until the end of June.
> This makes the new enforcement date Thursday, June 30th, 2011.
> Below is a list of the features we are adding in response to your requests and feedback:
> 1. Adding the force_login parameter to the /oauth/authorize screen to ensure the /authorize screen displays a login screen.
> 2. Adding the screen_name parameter to the /oauth/authorize and /oauth/authenticate requests. When provided with the force_login parameter we will pre-fill the username box on the OAuth screen.
> 3. Adding a "Back to app" button on the webpage which is loaded if a user selects "no, thanks". When selected the "Back to app" button will open the provided oauth_callback URL with a 'denied' parameter. The value of the denied parameter will be the request_token obtained from the /request_token request.
> For example: http://example.com/callback/?denied=xyz123abc
> 4. Design updates to the OAuth screens to improve compatibility across devices.
> 5. A lightweight OAuth screen flow for devices which are slow or incompatible with the new screens.
> 6. A new header on authenticated requests which tells you the access level of the oauth_token you are using. The header is available now and is called X-Access-Level. More information for this is available here:
> https://dev.twitter.com/pages/application-permission-model-faq
> Thanks for working with us to ensure users can make informed decisions about the access an application has to their account.
> Best
> @themattharris
> Developer Advocate, Twitter
> http://twitter.com/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
