Re: [twitter-dev] Re: The new permission model (R / RW / RWD) is now in effect
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 -- 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] Re: The new permission model (R / RW / RWD) is now in effect
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 Singletary On Fri, Jul 1, 2011 at 11:42 AM, Jeff Dairiki dair...@dairiki.org wrote: 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 -- 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] Re: The new permission model (R / RW / RWD) is now in effect
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 Singletary On Fri, Jul 1, 2011 at 11:42 AM, Jeff Dairiki dair...@dairiki.org wrote: 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 -- 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] Re: The new permission model (R / RW / RWD) is now in effect
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 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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com wrote:
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?
On Jun 30, 11:39 am, Arnaud Meunier arn...@twitter.com wrote:
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
--
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 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] Re: The new permission model (R / RW / RWD) is now in effect
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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com wrote:
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?
On Jun 30, 11:39 am, Arnaud Meunier arn...@twitter.com wrote:
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
--
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 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] Re: The new permission model (R / RW / RWD) is now in effect
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
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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com wrote:
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?
On Jun 30, 11:39 am, Arnaud Meunier arn...@twitter.com wrote:
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
--
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 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] Re: The new permission model (R / RW / RWD) is now in effect
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
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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com wrote:
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?
On Jun 30, 11:39 am, Arnaud Meunier arn...@twitter.com wrote:
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
--
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] Re: The new permission model (R / RW / RWD) is now in effect
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 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 http://twitter.com/intent/user?screen_name=episod - Taylor
Singletary
On Thu, Jun 30, 2011 at 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/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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com
wrote:
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?
On Jun 30, 11:39 am, Arnaud Meunier arn...@twitter.com wrote:
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
[twitter-dev] Re: The new permission model (R / RW / RWD) is now in effect
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,
@episod http://twitter.com/intent/user?screen_name=episod - Taylor
Singletary
On Thu, Jun 30, 2011 at 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
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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com
wrote:
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
[twitter-dev] Re: The new permission model (R / RW / RWD) is now in effect
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,
@episod http://twitter.com/intent/user?screen_name=episod - Taylor
Singletary
On Thu, Jun 30, 2011 at 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
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
On Thu, Jun 30, 2011 at 11:56 AM, Chris Teso christ...@gmail.com
wrote:
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?
On Jun 30, 11:39 am, Arnaud Meunier arn...@twitter.com wrote:
Hey Developers,
As planned, the new three-tier permission model is now officially in
effect.
Re: [twitter-dev] Re: The new permission model (R / RW / RWD) is now in effect
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 -- 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
