Thanks,
Jim Cortez
> --
> 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
> <https://groups.google.com/forum/#%21forum/twitter-development-talk>
Of course, for desktop (and mobile) applications this will mean that
they will have to integrate the normal OAuth flow. "Yay!".
In the past, I've seen several occurrences where popular clients weren't
affected by the rules. Will we yet again see this, or will there not be
an exception for those clients? The same question goes for Twitter's own
apps: will they make the switch to OAuth, or will they keep using xAuth?
Tom
On 5/18/11 7: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 on https://dev.twitter.com/apps and 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 to
> https://api.twitter.com/1/direct_messages/sent.json will 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
"A mathematician is a device for turning coffee into theorems." -- Paul
Erdos
Quoting Matt Harris <themat...@twitter.com>:
--
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
There have been a lot of opinions voiced about how this is being implemented. This not only proves troublesome for xAuth clients, but it lends me to worry about how the future of permissions will evolve. Effectively now, every single Twitter user needs to get their application re-authed for the new tokens to provide DM access by the end of the month.
The Facebook style of using a 'scope' for individual permissions is so much more viable. I also believe that the API should provide a lookup for the permissions that a set of credentials currently provides. I honestly believe that going down the 'scope' route for permissions will be a lot better for all concerned. When new permissions are introduced to the API in the future, it would be a small matter of updating the requesting scope for the application developer, rather than completely rewriting chunks of code.
I'd like a response from Matt, Taylor or Raffi on this matter and the plans for future permissions and their implementation.
> --
> 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
--
Scott Wilcox
@dordotky | sc...@dor.ky | http://dor.ky
+44 (0) 7538 842418 | +1 (646) 827-0580
+1
--
Martin Dapas
Agreed.
I'm really disappointed with this change.
Asking users to reauthorize is a burden on both developers and users.
Existing users already gave their permission for apps to access
private messages.
The lead time for developers to respond to this change is ridiculously short.
In my opinion, Twitter should have allowed users finer grained control
over permissions, allowing them to selectively remove "private
message" permissions for existing apps.
An app should be able to request a set of default permissions. Users
should be able to accept the defaults, or selectively deny individual
permissions.
If an app has optional "private message" features, it must request
"private message" permission from *all* users. Either that or
register multiple apps for each set of appropriate permissions, which
is confusing and difficult for users and developers to manage.
Is it too late to re-think this, Twitter?
-Marc
I have updated my apps to use Read/Write/DM permissions, and then it
saves it as Read-Only... I tried to change it back to just Read/Write,
and again it is saved as Read-Only.
Is anyone else having this problem? Users are going insane...
-Chad
so use http://dev.twitter.com/apps
and DO NOT USE http://twitter.com/apps (which, should be deleted or
auto-forwarded or something....)
caramba,
-chad
> We know this will take some time so we are allowing a transition period until the end of this month.
Gentlefolk,
This is way too short an amount of time to implement OAuth and transition mobile users off of an xAuth based client. (In my experience, my user base upgrades an app over a full quarter of a year.) Furthermore, even if I was ready right now with a submission to Apple, there is a very good chance that my app would not be approved by your deadline.
Please reconsider this deadline.
Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@DDG.com, +1 (512) 750-7596, twitter.com/adonoho
"We did not come to fear the future.
We came here to shape it."
-- President Barack Obama, Sept. 2009
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 on https://dev.twitter.com/apps and 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 requestsOn 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 activatedWhen 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 to https://api.twitter.com/1/direct_messages/sent.json will 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-modelWe have also blogged about this on the Twitter blog: http://blog.twitter.com/2011/05/mission-permission.htmlBest,@themattharris
--
My assumption is that it will stay in this state until they activate it. Is this right, or do we have to pass an extra permission parameter?
Sent from my iPod
This is all about clients having a large control over the twitterverse and the mismanagement of the situation by Twitter execs. Seeing us instead as competitors for the same resource. To disguise this as a security issue is laughable at best and a bit insulting. You have to realize the benefit Twitter is getting to know why they are doing this. It isn't mandatory to break all the client apps to make this change, but its convenient for Twitters current attack scheme on client apps.
This will cause mass exodus from 3rd party apps. If you have an app now, you are about to face a wave of pissed off people and bad reviews. There is no way you can realistically avoid this, and they know that. Thats the real meaning for this not because we all wanted it and have been requesting it. No serious Dev would want this. Maybe we want some more security options like Facebook has but we don't want to ruin our relationship with our customers to get it.
Twitter should hire some people with sense enough to know how to work with developers. It is no secret that Twitter is at war with the devs, so just tell us yes or no. You want us or you don't. Opening up for developers helped grow Twitter, now they don't need us anymore so they want to weed us out because "we control too much of their market" again, the same market we all created for them.
All this whole thing does is make people weary of client apps with saying we can access their DM's and then a whirlwind of confusion and complaints from our users will guarantee we loose many many users. Think about the normal person that uses tweetdeck. They will load the all, see nothing, and think its broken. If they figure out they need to confirm their info again and accept new permissions, they will be confused and weary as to why they have to do that. There is NO positive outcome for developers or their customers on this. It's a shame that we keep getting slammed with these sneaky back door slaps in the face disguised as some enhancement for users and more laughable, developers.
> To disguise this as a security issue is laughable at best and a bit insulting.
As USAmericans learned after 9/11/2001, you can push through just
about any policy you want if you wrap it up as security.
It's just astounding to watch Twitter, Inc. ignore the realities of
the developers' world when it takes weeks to get an app through
Apple's App Store process yet Twitter feels like they can just
announce this change and a 30 day deadline.
One might almost wonder if this wasn't yet another attempt to
discourage 3rd party developers from "competing" with Twitter's own
apps. And when you're done wondering about that, think about this:
what rule will Twitter change next?
"Twitter's fall from grace as the best API platform to the most
developer hostile is an exciting trainwreck to watch."
— http://twitter.com/justinw/status/70922532915642368
Then there was John Gruber's
http://daringfireball.net/linked/2011/05/18/twitter-translation:
> Translation From Weasel-Speak to English of the Key Question in Twitter’s FAQ for Developers Regarding Their New Policy for Third-Party Client Apps
>> Q: Will Twitter’s own applications also go through the OAuth web flow?
>> A: 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.
> Translation: No.
Or as I said yesterday: https://twitter.com/#!/TJLuoma/status/70954138103586816
> Shorter Message from @Twitter to 3rd Party Devs: "This is Phase One of getting rid of xAuth and Phase Two of getting rid of 3rd party devs."
First they came for basic auth…
TjL
Will Twitter's own applications also go through the OAuth web flow?
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.
On Thursday, May 19, 2011 at 4:58 PM, Frank Ash wrote:
I'll give an example for people using multiple accounts. From a customer point of view. I have 12 Twitter accounts, and I use 3 separate clients for different things. When this comes out I will have to re-authorize 36 times over these 3 apps alone. And they won't work until I do. If I was a normal user and didnt hear about the change, what am I going to think about this? I can already tell you I don't want to do it, and its gonna take a lot of time just to get these apps working again. That is for a power user though. Now someone like my mom who uses tweetdeck just to follow celebrities, she will have no clue what happened or why its not working and will be weary when tweetdeck asks her to confirm a new permissions scheme and wonder why they want her info again. Just step back and look at it for what it is and how people will react. We all know what's going to happen.
Also there is no way Twitter will make themselves do the same thing. Lol that would be hilarious. They will in no way form or fashion make all their users go through this process. That would be something I would be fine with. If they want this change, let them do it also lol. But yeah, there is no way they would, because they know exactly what would happen.
We’re taking this step to give more clarity and control to users aboutWill Twitter's own applications also go through the OAuth web flow?
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.
On Thursday, May 19, 2011 at 5:22 PM, Frank Ash wrote:
Cartmetrix, We don't know for sure what will happen. That's kinda the problem. My guess is we all prepare now by making our app request rwdm access, then when the switch takes effect any token that has been changed with this update will then need to be reauthorized. Not effecting us now, but when that change takes hold, I imagine all our tokens will be basically unauthorized because its an all new permission request, thus forcing each user to accept the new authorizations before they can use the app to communicate with the Api. Also I spoke unclear earlier about all apps failing. It will only be ones that use DM as a feature. Which is basically any client app. I just assume everyone here is effected by the DM permission change in some way, so I say all our apps. But little Twitter apps that just read and write won't be effected at all. Because Twitter isn't afraid of them, just client apps.
Also there is no way Twitter will make themselves do the same thing. Lol that would be hilarious. They will in no way form or fashion make all their users go through this process. That would be something I would be fine with. If they want this change, let them do it also lol. But yeah, there is no way they would, because they know exactly what would happen.
I am interested also to here the way they will dance around not doing this themselves as well. They won't, I can guarantee that. I would bet my house on it. Eiyer way the outcome will be negative in any scenario, so they won't want any part of that. But they think its fine if we have to.
"We just started to return the "X-Access-Level" header for
authenticated API requests, that tells you what access level the user
token has"
James