The new permission model (R / RW / RWD) is now in effect

[Arnaud Meunier]

Hey Developers,

As planned, the new three-tier permission model is now officially in effect. Please remember that you don't have to make any changes if your application or service doesn't need to read or delete Direct Messages.

Key points:

- Existing oauth_tokens have not (and will not) be invalidated, even if you update your application permission level.

- Read/Write and Read tokens are now unable to read and delete Direct Messages. If you wish to read or delete a user's Direct Messages, you need to update your application and have your existing access tokens reauthorized through the OAuth authorize web flow.

- All authenticated API requests return an "X-Access-Level" header, so you can find out the current permission level of the access token you're using (read, read-write, or read-write-directmessages).

For more information, be sure to take a look on:

- The Application Permission Model documentation page: http://t.co/elH0KY4

- The Application Permission Model FAQ: http://t.co/1Wliqg4

Thanks again for working with us on this new permission level,

Arnaud / @rno

[Chris Teso]

I assumed that the new permissions would not apply to an app reading
it's own DMs. ie: When authenticating with an apps own token and
secret /1/direct_messages.{format} should not enforce the R/W/DM
policy.

Appears this is not the case?

[Arnaud Meunier]

Hey Chris,

The new permission model applies to all access tokens, including the application owner's one. You have to reauthorize your existing access_token through the OAuth Flow, just like any other user.

Arnaud / @rno

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

[Taylor Singletary]

Additionally, newly generated tokens with the  "My Access Token" feature on dev.twitter.com will now return an access token at the same level of access your application requests. 

If you used "My Access Token" to generate your token in the past, you'll want to first go to http://twitter.com/settings/applications to revoke your access token's permissions and then go back to dev.twitter.com's My Access Token feature to re-negotiate an upgraded token.

Any token that transitions from one state to another will have the string representation of the access token and secret changed: If a token goes from RO to RW, the strings will change. If a token goes from RW to RWD, the strings will change. If a user revokes a token and you then renegotiate the token, even if the permission level didn't change, the strings will change.

Thanks,
@episod - Taylor Singletary

[Chris Teso]

Arnaud & Taylor,

Thanks for the response. I must say that I'm confused as to why the
decision was made to block ones own app from reading their own DMs?
Can you elaborate on the logic behind this decision?

It seems logical that I would not have to re-authorize my own app
tokens to view my own DMs. Further, I do not want to change my apps
permission levels to do so. This effects ALL of our customers solely
so I can read my own apps DMs! If I follow Taylors suggested new token
request, can I then revert my apps permissions and still access my
apps own dms? ie: I DEFINITELY do not want to keep my app permissions
set to R/W/DM when I don't need to access any customer DM data.

Thanks,
Chris


On Jun 30, 12:17 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> Additionally, newly generated tokens with the  "My Access Token" feature on
> dev.twitter.com will now return an access token at the same level of access
> your application requests.
>
> If you used "My Access Token" to generate your token in the past, you'll

> want to first go tohttp://twitter.com/settings/applicationsto revoke your

> access token's permissions and then go back to dev.twitter.com's My Access
> Token feature to re-negotiate an upgraded token.
>
> Any token that transitions from one state to another will have the string
> representation of the access token and secret changed: If a token goes from
> RO to RW, the strings will change. If a token goes from RW to RWD, the
> strings will change. If a user revokes a token and you then renegotiate the
> token, even if the permission level didn't change, the strings will change.
>
> Thanks,

> @episod <http://twitter.com/intent/user?screen_name=episod> - Taylor

> Singletary
>
>
>
>
>
>
>
> On Thu, Jun 30, 2011 at 12:11 PM, Arnaud Meunier <arn...@twitter.com> wrote:
> > Hey Chris,
>
> > The new permission model applies to all access tokens, including the
> > application owner's one. You have to reauthorize your existing access_token
> > through the OAuth Flow, just like any other user.
>

> > Arnaud / @rno <http://twitter.com/rno>

[Rich]

I'm seeing a number of users, and it is a minority but still, getting
403 errors

Some if these users haven't even auth'd before I changed the app
permissions.

I know it's not a global app issue as the vast majority of my users
can still access dms, including me

On Jun 30, 8:27 pm, Chris Teso <christ...@gmail.com> wrote:
> Arnaud & Taylor,
>
> Thanks for the response. I must say that I'm confused as to why the
> decision was made to block ones own app from reading their own DMs?
> Can you elaborate on the logic behind this decision?
>
> It seems logical that I would not have to re-authorize my own app
> tokens to view my own DMs. Further, I do not want to change my apps
> permission levels to do so. This effects ALL of our customers solely
> so I can read my own apps DMs! If I follow Taylors suggested new token
> request, can I then revert my apps permissions and still access my
> apps own dms? ie: I DEFINITELY do not want to keep my app permissions
> set to R/W/DM when I don't need to access any customer DM data.
>
> Thanks,
> Chris
>
> On Jun 30, 12:17 pm, Taylor Singletary <taylorsinglet...@twitter.com>
> wrote:
>
>
>
> > Additionally, newly generated tokens with the  "My Access Token" feature on
> > dev.twitter.com will now return an access token at the same level of access
> > your application requests.
>
> > If you used "My Access Token" to generate your token in the past, you'll

> > want to first go tohttp://twitter.com/settings/applicationstorevoke your

[Chris Teso]

Ok, I just went through the following exercise:

1. changed app permissions to R/W/DM
2. reset oauth tokens and updated my app
3. reverted app permissions to R/W

And BOOM. Can't access my own apps DMs even with new token perms. So,
I guess I need to have ALL of our customers approve our app to read
their DMs solely so I can read my own!! I also need to have them use
the Authorize flow rather than Sign in.

Can anything be done to help me out here? To me it's obvious that
customers should not have to authorize their accounts just to give my
app permission to read it's own DMs. This is a huge downer.

On Jun 30, 12:27 pm, Chris Teso <christ...@gmail.com> wrote:
> Arnaud & Taylor,
>
> Thanks for the response. I must say that I'm confused as to why the
> decision was made to block ones own app from reading their own DMs?
> Can you elaborate on the logic behind this decision?
>
> It seems logical that I would not have to re-authorize my own app
> tokens to view my own DMs. Further, I do not want to change my apps
> permission levels to do so. This effects ALL of our customers solely
> so I can read my own apps DMs! If I follow Taylors suggested new token
> request, can I then revert my apps permissions and still access my
> apps own dms? ie: I DEFINITELY do not want to keep my app permissions
> set to R/W/DM when I don't need to access any customer DM data.
>
> Thanks,
> Chris
>
> On Jun 30, 12:17 pm, Taylor Singletary <taylorsinglet...@twitter.com>
> wrote:
>
>
>
>
>
>
>
> > Additionally, newly generated tokens with the  "My Access Token" feature on
> > dev.twitter.com will now return an access token at the same level of access
> > your application requests.
>
> > If you used "My Access Token" to generate your token in the past, you'll

> > want to first go tohttp://twitter.com/settings/applicationstorevoke your

[Taylor Singletary]

Hi Chris,

With the one exception of Site Streams' authorization pattern, there is no "special relationship" between the account owner of an application and the application itself -- you are just a user of your application, same as any other user. I'm sorry that wasn't clear.

You have a few options in this scenario and I'm sure one of them will be "right" for you.

* Option 1: Create a side-car application record for the purpose of reading and responding to DMs. Set your permission level on this app to RWD. Issue your own access token. Use this consumer key and secret for the portion of your application that needs to read/write DMs. You would code your application to use the appropriate set of keys for the appropriate situation. This separates concerns and would have other benefits. If your app tweets on its own behalf, you'd want to use your primary API keys so that you're attributed the way you like. When creating an app for this purpose, be sure and clearly label its intent and purpose.

* Option 2: There's a feature we've added to the OAuth flow that allows you to specify the level of permissions you are asking for at the time of the request. In this scenario, you would set your application to RWD but explicitly request your end-users to receive only RW tokens by passing the parameter "x_auth_access_type=write" to api.twitter.com/oauth/request_token on the first step of the OAuth song and dance. When negotiating your own token, you'll ask for a RWD but for all end-user tokens, only RW. You leave your application at the RWD level. More details on this option are at http://dev.twitter.com/doc/post/oauth/request_token

Either of these options seem suitable for your scenario, with the first option likely being your quickest solution and also the most preferable. Unless you have a requirement to share access tokens between arms of the application, it's a great approach for separating concerns in an app.

Let me know if you have any questions on this.

Thanks,

@episod - Taylor Singletary

[Chris Teso]

Option #1 sounds perfect and will work. Thank you for the idea.

A larger issue now seems that we lost our white listing when resetting
the tokens. I realize this should not be the case, however I have
confirmed this is not an un-OAuthed issue. All API calls are going
through fine. Our rate limit has been reset though to 150/hr.


On Jun 30, 1:02 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> Hi Chris,
>
> With the one exception of Site Streams' authorization pattern, there is no
> "special relationship" between the account owner of an application and the
> application itself -- you are just a user of your application, same as any
> other user. I'm sorry that wasn't clear.
>
> You have a few options in this scenario and I'm sure one of them will be
> "right" for you.
>
> * Option 1: Create a side-car application record for the purpose of reading
> and responding to DMs. Set your permission level on this app to RWD. Issue
> your own access token. Use this consumer key and secret for the portion of
> your application that needs to read/write DMs. You would code your
> application to use the appropriate set of keys for the appropriate
> situation. This separates concerns and would have other benefits. If your
> app tweets on its own behalf, you'd want to use your primary API keys so
> that you're attributed the way you like. When creating an app for this
> purpose, be sure and clearly label its intent and purpose.
>
> * Option 2: There's a feature we've added to the OAuth flow that allows you
> to specify the level of permissions you are asking for at the time of the
> request. In this scenario, you would set your application to RWD but
> explicitly request your end-users to receive only RW tokens by passing the
> parameter "x_auth_access_type=write" to

> api.twitter.com/oauth/request_tokenon the first step of the OAuth song

> and dance. When negotiating your own
> token, you'll ask for a RWD but for all end-user tokens, only RW. You leave

> your application at the RWD level. More details on this option are athttp://dev.twitter.com/doc/post/oauth/request_token

>
> Either of these options seem suitable for your scenario, with the first
> option likely being your quickest solution and also the most preferable.
> Unless you have a requirement to share access tokens between arms of the
> application, it's a great approach for separating concerns in an app.
>
> Let me know if you have any questions on this.
>
> Thanks,

[Chris Teso]

It appears the token and secret have be re-reset and needed time to
take effect. Rate limit is back up.

On Jun 30, 1:02 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> Hi Chris,
>
> With the one exception of Site Streams' authorization pattern, there is no
> "special relationship" between the account owner of an application and the
> application itself -- you are just a user of your application, same as any
> other user. I'm sorry that wasn't clear.
>
> You have a few options in this scenario and I'm sure one of them will be
> "right" for you.
>
> * Option 1: Create a side-car application record for the purpose of reading
> and responding to DMs. Set your permission level on this app to RWD. Issue
> your own access token. Use this consumer key and secret for the portion of
> your application that needs to read/write DMs. You would code your
> application to use the appropriate set of keys for the appropriate
> situation. This separates concerns and would have other benefits. If your
> app tweets on its own behalf, you'd want to use your primary API keys so
> that you're attributed the way you like. When creating an app for this
> purpose, be sure and clearly label its intent and purpose.
>
> * Option 2: There's a feature we've added to the OAuth flow that allows you
> to specify the level of permissions you are asking for at the time of the
> request. In this scenario, you would set your application to RWD but
> explicitly request your end-users to receive only RW tokens by passing the
> parameter "x_auth_access_type=write" to

> api.twitter.com/oauth/request_tokenon the first step of the OAuth song

> and dance. When negotiating your own
> token, you'll ask for a RWD but for all end-user tokens, only RW. You leave

> your application at the RWD level. More details on this option are athttp://dev.twitter.com/doc/post/oauth/request_token

>
> Either of these options seem suitable for your scenario, with the first
> option likely being your quickest solution and also the most preferable.
> Unless you have a requirement to share access tokens between arms of the
> application, it's a great approach for separating concerns in an app.
>
> Let me know if you have any questions on this.
>
> Thanks,

[Jeff Dairiki]

On Thu, Jun 30, 2011 at 01:02:45PM -0700, Taylor Singletary wrote:
>
> * Option 2: There's a feature we've added to the OAuth flow that allows you
> to specify the level of permissions you are asking for at the time of the
> request. In this scenario, you would set your application to RWD but
> explicitly request your end-users to receive only RW tokens by passing the
> parameter "x_auth_access_type=write" to

> api.twitter.com/oauth/request_tokenon the first step of the OAuth song

> and dance. When negotiating your own
> token, you'll ask for a RWD but for all end-user tokens, only RW. You leave
> your application at the RWD level. More details on this option are at
> http://dev.twitter.com/doc/post/oauth/request_token

Is it possible to (leave) the app default access level set at RW, but
use x_auth_access_type to request RWD access for a specific account?

It seems like it should be, however the docs for request_token only
mention two possible values --- 'read' and 'write' --- for
'x_auth_access_type'.

Thanks for any help!

Cheers,
Jeff

[Reivax]

Hi,

Can someone have a look at this bug http://code.google.com/p/twitter-api/issues/detail?id=2257

Can we hope for a fix ?

You really blew it guys.
We were ready for one month for this change, but then you leave one
access broken, and it's the one we use.

We lost thousands of users last night because of this bug.

I hope I can get an answer here, because your so called "support"
twitter account, your irc channel, your bug report tool didn't help
much so far.

Thanks !

Xavier

[Rich]

It's not broken /oauth/authenticate was never intended to have DM
access https://dev.twitter.com/pages/application-permission-model-faq

"You said you were restricting this permission to the OAuth /authorize
web flow only. Will /oauth/authenticate (Sign in with Twitter) support
the new permission?

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

On Jul 1, 6:54 am, Reivax <xavier.yo...@gmail.com> wrote:
> Hi,
>

> Can someone have a look at this bughttp://code.google.com/p/twitter-api/issues/detail?id=2257

[Jeff Dairiki]

To restate my question of yesterday:

It has been (and is still) possible to set the "default access type"
for ones app to "Read-only", yet still get read/write tokens by passing
"x_auth_access_type=write" to /oauth/request_token.

Is there a corresponding value for x_auth_access_type which will
yield a read/write/direct-message token?

(The docs at http://dev.twitter.com/doc/post/oauth/request_token list
only the choices 'read' and 'write'. If there really is no third
value to be used to request a r/w/dm token, this would seem to me ---
in light of the recent permission model changes --- to be an
oversight.)

I've just filed a ticket on this:

http://code.google.com/p/twitter-api/issues/detail?id=2258

Thanks for any help!

Jeff

[Taylor Singletary]

Hi Jeff,

There's no way to specify a RWD option on this method -- if your application requires the use of direct messages in any context, you must set that at the application level. 

This parameter will only influence the creation of RO or RW tokens.

@episod - Taylor Singletary

[Jeff Dairiki]

Hi Taylor,

Thank you for the quick reply.

Is there a good reason for that limitation? Or is there some hope
that in the future request_token will be enhanced to enable
explicit request of a RWD token?

In the mean time, I'll figure out the best way to get by.

Thanks again.

Jeff

On Fri, Jul 01, 2011 at 11:59:11AM -0700, Taylor Singletary wrote:
> Hi Jeff,
>
> There's no way to specify a RWD option on this method -- if your application
> requires the use of direct messages in any context, you must set that at the
> application level.
>
> This parameter will only influence the creation of RO or RW tokens.
>

> @episod <http://twitter.com/intent/user?screen_name=episod> - Taylor

[G@bo]

Why if my app has (R / RW / DM) permission model, in twitter when user
registered by OAUTH appears like APP has not DM level?

Twitter page saids: This app will not be able to:
- Access your direct messages
- See your twitter password

Thanks.

[Amit]

Hi Arnaud,

We are developing twitter App for iPhone implemented all the stuff.
Everything was working previously with XAuth but right now it is
causing problem in Direct Message.

I know that it is working with OAuth, Can you please tell me is there
any chances to get this done using XAuth in coming days. If yes then
how long we have to wait otherwise we have to go through OAuth for
implementing Direct Message.

Please give me reply ASAP we are in between to finish the App.

Thanks,
Amit

[Rich]

Twitter have stated that XAuth will no longer have access to Direct
Messages and you MUST make the switch to the full OAuth workflow
through /authorize if you wish to get access to a user's Direct
Messages