[twitter-dev] A new permission level
Did anyone else change their permission on Twitter to rwdm and now their app doesn't show anything? I changed mine, and today I had to reauthorized my account because nothing would load inTo the app. Now it works as usual after I re added my info. Am I the only one? could possibly just be a glitch idk. -- 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
Re: [twitter-dev] A new permission level
Hi Matt,
I have started implementing these changes. The app's permissions setting is
set to Read, Write DM (the new one).
However, when the user gets redirected to the auth page, it still indicates
that the app will not be able to read or send DM's. Is this something that
will automatically happen when you activate it, or is there a permissions
parameter I should send to the auth page?
Adriaan Pelzer
//))//\\//\\||//
//\\//7//7///\\
putting you in touch with your crowds
http://www.wewillraakyou.com
http://www.wewillraakyou.comtwitter: http://www.twitter.com/adriaan_pelzer
linkedIn: http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
skype: adriaan_pelzer
http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
+4478 7978 1743
On Wed, May 18, 2011 at 6:01 PM, Matt Harris thematthar...@twitter.comwrote:
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:
[twitter-dev] A new permission level
I wish they would just tell the developers to go to hell in a way and let us know they hate us instead of doing these back handed attacks on our apps all the time. This has very very little to do with privacy. Especially for the developer that wants to abuse accounts, this doesn't stop them and serves no real purpose. And putting it to the media as we having access to their DM's is misguided at best. Users now think we are reading their DM's and have access to monitoring their conversations. Which is just crap. 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. -- 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
Re: [twitter-dev] A new permission level
On that day when your users open up our various clients and see issues with direct messages I suggest you insert your own DMs to your users with succinct descriptions to the root of the problem and links to further info. It looks like there is no way to prevent having to update apps for those that can, but you certainly have the platform and your customer's eyeballs at the exact point of failure to explain. We all know not everyone is going to read the email we are all dreading to send, at least this way we have another method to get the point to them at the exact time they need it. On Thursday, May 19, 2011 at 4:18 PM, Frank Ash wrote: I wish they would just tell the developers to go to hell in a way and let us know they hate us instead of doing these back handed attacks on our apps all the time. This has very very little to do with privacy. Especially for the developer that wants to abuse accounts, this doesn't stop them and serves no real purpose. And putting it to the media as we having access to their DM's is misguided at best. Users now think we are reading their DM's and have access to monitoring their conversations. Which is just crap. 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. -- 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 -- 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
Re: [twitter-dev] A new permission level
On Thu, May 19, 2011 at 5:18 PM, Frank Ash nut...@gmail.com wrote: 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 -- 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
[twitter-dev] A new permission level
Yes janol, everything but twitters official apps will fail. This is specifically aimed at client apps. It is a way to specifically Target client apps because it deals only with DM's which are mostly viewed through client applications. And specifically you said even tweetdeck, I would say especially tweetdeck. They control the largest amount of users outside of the official app and they have been attacking these large clients for some time now. By directly targeting DM's only it should be obvious to everyone why they are doing this. It's presented as some small change but the fallout for clients will be insane. You can't spin the news in a way to make it sound positive or even necessary. It's going to cause a storm of user confusion, deleted apps, bad reviews, complaints to customer support, uncertainty as to why they have to regive permission and religion their accounts. And if you app holds multiple accounts, your in for a nightmare. No one will want to go through putting all their info back into the app. -- 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
[twitter-dev] A new permission level
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. -- 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
Re: [twitter-dev] A new permission level
Frank- Correct me if I'm wrong, but the applications won't quit working altogether. You'll get a 403 error when trying to access DMs through the API. Everything else should work as normal. Has there been a better official answer if this affects Twitter's own apps other than this: 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. Which doesn't quite answer my question or the one it's supposed to. cheers damonp 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. -- 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 -- 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
[twitter-dev] A new permission level
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. -- 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
Re: [twitter-dev] A new permission level
Frank-
http://dev.twitter.com/pages/application-permission-model-faq
The way I read the FAQ posted is _only_ apps requiring DM read access will be
affected under the following endpoints:
/1/direct_messages.{format}
/1/direct_messages/sent.{format}
/1/direct_messages/destroy.{format}
/1/direct_messages/show.{format}
These will receive an HTTP 403 with:
{errors:[{code:93,message:This application is not allowed to access or
delete your direct messages}]}
In fact, it explicitly says:
Yes. Read/Write tokens can send direct messages using direct_messages/new.
Which doesn't quite make sense from a security standpoint... but I'm not going
to argue.
Unless this is all PR spin, the only thing that seemed unclear was whether
Twitter's own apps would require re-authorization into the new perms. The only
thing that addresses that was what I posted previously:
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.
Which says they'll be subject to oAuth web flow... but as I understand it, they
already are. It says nothing about the re-auth steps for the own apps.
Maybe someone from Twitter will provide a more clear response regarding re-auth
of their own apps instead of an ambiguous answer. This could defuse some
developer concern and conspiracy theory conjecture.
Damon
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.
--
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
--
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
[twitter-dev] A new permission level
That would be much better cartmatrix but either way, its a negative and unnecessary to take this approach. I am still a bit sceptical that everything will still work fine, just if they try to send a DM it will fail to a 403 error. There is language in the post that suggests both outcomes as possible. I would really like someone from Twitter to clarify exactly what will happen. Very clearly and plainly. 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. -- 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
[twitter-dev] A new permission level
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
--
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
Re: [twitter-dev] A new permission level
Matt,
You say:
This means applications which use xAuth and want to access direct
messages must send a user through the full OAuth flow.
What if the client using xAuth has no browser and therefore cannot go
through oAuth? Does this mean that direct messages cannot be accessed?
Is there a process I can go through to get our app approved for use of
direct messages without using oAuth?
Thanks,
Jim Cortez
On 5/18/11 10:01 AM, 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
--
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
Re: [twitter-dev] A new permission level
Sounds good! Also sounds like you folks are finally trying to get rid of
xAuth :-)
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
--
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
Re: [twitter-dev] A new permission level
--
http://twitter.com/znmeb http://borasky-research.net
A mathematician is a device for turning coffee into theorems. -- Paul
Erdos
Quoting Matt Harris thematthar...@twitter.com:
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
--
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
--
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
Re: [twitter-dev] A new permission level
On May 18, 2011, at 12:01 , Matt Harris wrote: 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 -- 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
