[twitter-dev] Re: Open DM availability only for Verified Accounts?
Bump. We'd love to be verified at http://sellsimp.ly as we have core functionality that relys on DMs. If users could Dm without us following it would be of great assistance. Thanks, Chris On Jul 5, 8:39 am, Ryan wrote: > Searched this forum and found nothing, but apparently you guys are rolling > out a new feature for Verified accounts to be able to receive DM's without > having to follow back each user. > > See:http://thenextweb.com/twitter/2011/07/04/twitter-drops-following-requ... > > This leads to multiple questions: > > 1) Is it possible for regular small businesses to gain verified status? Or > is this just limited to mega brands/businesses? Obviously this feature > would be very helpful to more than just the select few "verified" business > accounts. > > 2) Why not let any user apply this feature in their settings panel? If > worried about DM spam, I don't really see the downside as they would only be > inflicting spam on themselves. Any chance of this happening? > > 3) Can verified users turn this off if its not desirable for their specific > situation? > > Thanks, > Ryan -- 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
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 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 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 > > 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 > > wrote: > > > > Hey Chris, > > > > > The new permission model applies to all access tokens, inclu
[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 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 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 > > 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
[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 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
> 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 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 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 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:
[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
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 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 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 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: GET statuses/retweets/:id
Ah, ok. Seems you need to specify count param to be accurate. On Jun 26, 10:22 pm, Chris Teso wrote: > The documentation athttp://dev.twitter.com/doc/get/statuses/retweets/:id > states it will return up to 100 of the first retweets of a given > tweet. > > However, in practice the method seems to only return the recent > Retweets for a given Tweet. > > Take these two urls:http://www.flickfolia.com/freeshows 17 Retweets. > This url is using the api to return > Retweets.http://twitter.com/#!/Flickfolia/status/85127683410886656shows that > there has been 29 Retweets. > > Note: The stats are as of the time of this post. -- 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] GET statuses/retweets/:id
The documentation at http://dev.twitter.com/doc/get/statuses/retweets/:id states it will return up to 100 of the first retweets of a given tweet. However, in practice the method seems to only return the recent Retweets for a given Tweet. Take these two urls: http://www.flickfolia.com/free shows 17 Retweets. This url is using the api to return Retweets. http://twitter.com/#!/Flickfolia/status/85127683410886656 shows that there has been 29 Retweets. Note: The stats are as of the time of this post. -- 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: Loading twitter javascript using https
@anywhere currently does not support https. As a work around you could download http://platform.twitter.com/anywhere.js locally and pull it off your server via https. This comes with it's own challenges, as you'll need to manually update when Twitter decides to update their codebase, but it will work. On May 5, 5:02 pm, Ahmed Aly wrote: > Hi everyone, > > I want to load twitter javascript (http://platform.twitter.com/anywhere.js) > but using https. > How can I do this? > > Thanks! -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: direct_messages/new
The Full http response is NULL.
The request sent is $this->connection->post('direct_message/new',
array( 'screen_name' => $username, 'text' => $text ) ) with proper
auth headers.
Again, the method works if we pass user_id rather than screen_name.
$this->connection->post( 'direct_messages/new', array( 'user' =>
19081905, 'text' => $text ) );
Using screen_name has been working for 4 months in our app, and
stopped working 2 days ago.
Thanks
On Apr 5, 10:02 pm, Arnaud Meunier wrote:
> Hey Chris,
>
> The endpoint is working fine with both parameters (just tested it).
>
> If you're still having this issue, think to provide more details (i.e.
> request sent with auth headers + Full HTTP response). Otherwise, people of
> this Mailing List won't be able to help you that much!
>
> Arnaud / @rno <http://twitter.com/rno>On Tue, Apr 5, 2011 at 4:34 PM, Chris
> Teso wrote:
> > direct_messages/new seems to have stopped working if using
> > screen_name.
>
> > The method works if passing user_id.
>
> > Can you confirm either way?
>
> > --
> > Twitter developer documentation and resources:http://dev.twitter.com/doc
> > API updates via Twitter:http://twitter.com/twitterapi
> > Issues/Enhancements Tracker:
> >http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group:
> >http://groups.google.com/group/twitter-development-talk
--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk
[twitter-dev] direct_messages/new
direct_messages/new seems to have stopped working if using screen_name. The method works if passing user_id. Can you confirm either way? -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
