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