I very much agree. To get xAuth, we all had to apply and undergo some
sort of verification process.

Also, if I take my app Gravity as an example, I am using xAuth (and
previously Basic Auth) since the very beginning and there have been
zero complaints from users that Gravity has been misusing the DM
feature.

Why? Well, it can't. It's a standalone, mobile application and not a
web app. I, as the author, do not have access to the users passwords
nor to their oAuth tokens.

Furthermore, Gravity is a client on the Symbian platform where you
cannot open the webbrowser for the OAuth flow on many phone models.
And there is no official client on the Symbian platform (although it
would be nice if it was Gravity :-))

Could you please re-consider this and either grandfather xauth clients
or offer a checkbox on the user's Twitter.com settings for the xAuth
clients where they can manually disable/enable DMs?

Wouldn't that be a very good decision for all xAuth clients anyway?
Just add a checkbox so the users can disable DMs if they really don't
want DMs in their mobile/etc. third party clients.

As a side note, the time to get an app through the OviStore (Nokia's
App Store) process can be quite long. I don't think 13 days will be
enough for this.

Cheers
Ole (@janole / @gravityapp)

On May 18, 7:49 pm, Paul Haddad <paul.had...@gmail.com> wrote:
> Hi Matt,
>
> 1.  xAuth apps are already approved by you guys and have a (I'm assuming) 
> higher threshold to get access to. I'd really ask you guys to re-consider and 
> allow xAuth access to DMs. Or at the very least allow clients to apply for 
> exceptions to this rule.
> 2.  Under 2 weeks is way too short of a time for this big of a change.
>
> On May 18, 2011, at 12:01 PM, Matt Harris wrote:
>
>
>
>
>
>
>
>
>
> > Hey everyone,
>
> > We recently updated our OAuth screens to give users greater transparency 
> > about the level of access applications have to their accounts. The valuable 
> > feedback Twitter users and developers have given us played a large part in 
> > that redesign and helped us identify where we can do more.
>
> > In particular, users and developers have requested greater granularity for 
> > permission levels.
>
> > In response to this feedback, we have created a new permission level for 
> > applications called “Read, Write & Direct Messages”. This permission will 
> > allow an application to read or delete a user's direct messages. When we 
> > enforce this permission, applications without a “Read, Write & Direct 
> > Messages” token will be unable to read or delete direct messages. To ensure 
> > users know that an application is receiving access to their direct 
> > messages, we are also restricting this permission to the OAuth /authorize 
> > web flow only. This means applications which use xAuth and want to access 
> > direct messages must send a user through the full OAuth flow.
>
> > What does this mean for your application?
> > If you do not need access to direct messages: you won’t need to make any 
> > changes to your application. When we enforce the new permission level your 
> > read or read/write token will automatically lose access to direct messages.
>
> > If you do need access to direct messages: you will need to edit your 
> > application record onhttps://dev.twitter.com/appsand change the permission 
> > level of your application to “Read, Write and Direct Messages”. The new 
> > permission will not affect existing tokens which means existing users or 
> > your app or service will need to reauthorize.
>
> > We know this will take some time so we are allowing a transition period 
> > until the end of this month. During this time there will be no change to 
> > the access Read/Write tokens have to a users account. However, at the end 
> > of the month any tokens which have not been upgrade to “Read, Write and 
> > Direct Messages” will be unable to access and delete direct messages.
>
> > Affected APIs and requests
> > On the REST API, Read and Read/Write applications will no longer be able to 
> > use these API methods:
> > /1/direct_messages.{format}
> > /1/direct_messages/sent.{format}
> > /1/direct_messages/show.{format}
> > /1/direct_messages/destroy.{format}
>
> > For the Streaming API, both User Streams and Site Streams will only receive 
> > direct messages if the user has authorised an application to access direct 
> > messages.
>
> > Applications that use “Sign-in with Twitter” or xAuth will only be able to 
> > receive Read or Read/Write tokens.
>
> > What this means is only applications which direct a user through the OAuth 
> > web flow will be able to receive access tokens that allow access to direct 
> > messages. Any other method of authorization, including xAuth, will only be 
> > able to receive Read/Write tokens.
>
> > What will happen when the permission is activated
> > When we activate the new permission, all Read and Read/Write user_tokens 
> > issued to third-party applications will lose their ability to read direct 
> > messages. Any attempt to read direct messages will result in an HTTP 403 
> > error being returned.
>
> > For example, a GET request 
> > tohttps://api.twitter.com/1/direct_messages/sent.jsonwill return an HTTP 
> > 403 Forbidden with the response body:
>
> > {"errors":[{"code":93,"message":"This application is not allowed to access 
> > or delete your direct messages"}]}
>
> > Key Points
> > * If you wish to access a user’s direct messages you will need to update 
> > your application and reauthorize existing tokens.
> > * The only way to get direct message access is to request access through 
> > the OAuth /authorize web flow. You will not be permitted to access direct 
> > messages if you use xAuth.
> > * When we enforce the permission Read/Write and Read tokens will be unable 
> > to access and delete direct messages.
> > * Read/Write tokens will be able to send direct messages after the 
> > permission is enforced.
>
> > We’ll be collating responses and adding more information on our developer 
> > resources permission model 
> > page:https://dev.twitter.com/pages/application-permission-model
>
> > We have also blogged about this on the Twitter 
> > blog:http://blog.twitter.com/2011/05/mission-permission.html
>
> > Best,
> > @themattharris
>
> > --
> > Twitter API documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Change your membership to this 
> > group:http://groups.google.com/group/twitter-api-announce?hl=en
>
> ---
> Paul Haddad
> paul.had...@gmail.com, p...@tapbots.com, p...@pth.com

-- 
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

Reply via email to