[twitter-dev] Twitter Streaming API blocked user
Hi, I'm using the streaming API (sitestream) and one of my user @thecivvie blocked @fabientest but if @fabientest tweets, I see those tweets for @thecivvie coming. Is that an implementation bug, is it supposed to be like this, or have I missed something? Thanks. -- 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] Block API call always fails for specific users
This is a follow up to an existing thread (which I am unable to reply to): http://groups.google.com/group/twitter-development-talk/browse_thread/thread/5a287ab379497e97/321508b2463573d7?lnk=gstq=block#321508b2463573d7 Our application is experiencing the exact same problem. The block API call often works but will consistently fail when trying to block certain accounts. For example, one of our users reported the error when trying to block @divadmarketing. I was able to recreate when trying to block this same user from my own account (no offense to the person who owns this account). Perhaps you will be able to recreate against this account too? As Thomas mentioned in the existing thread, the response is always a full page of HTML containing text that Twitter is currently over capacity. This is not an accurate message because we can recreate every single time we try and it only happens with specific users. Thanks, -Anil -- 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: Default Access type doesn't change after saving
Me too. What I was able to figure out is managing your application through https://twitter.com/apps/edit/ does not save the read-write property, but dev.twitter.com/apps does. On May 14, 12:29 pm, Ciarán McCann ciaran.mccann@gmail.com wrote: I currently have the same problem. Very strange. -- 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: Auto Populating Tweets Broken?
Hey There, +1. This issue is affecting all of our products at the moment. I can't find any notification anywhere about this being deprecated today. Please restore this functionality. And allow us some time to migrate w/ a date in mind. If it's no longer going to be supported, we need to know sooner as we have clients waiting for an answer at the moment. We would like to use intents, but we need a full page to send the user to since we can't always open a popup window (ie from Flash.) and that page doesn't look good in a full browser tab. Thanks, Omar On May 17, 3:05 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Yahel, Meet Web Intents:http://dev.twitter.com/pages/intents(take a look on the intent/tweet intent). It really is super easy to implement. For example:http://twitter.com/intent/tweet?text=foobar Arnaud / @rno http://twitter.com/rno On Tue, May 17, 2011 at 1:18 PM, Yahel Carmon yah...@gmail.com wrote: Hey, We've just noticed that auto-populating tweets using http://twitter.com/home/?status=foobarno longer works. Has this feature been totally removed, or is this a temporary glitch? (Perversely,http://twitter.com/?status=foobarworks, but that was the older method that broke last year and we were told to add /home to fix it.) I know we're supposed to move to the official Tweet button, but we have a very large scale CRM that still relies on the old method. Please let me know ASAP, as we have a lot of broken tweet links in the wild. Thanks, Yahel -- Yahel Carmon (917) 445-3498 Twitter:http://twitter.com/yahelc Facebook:http://facebook.com/yahel LinkedIn:http://www.linkedin.com/in/yahelc -- 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: New Status Using A Query String
+1. Thanks for the update Arnaud. This is affecting all of our customers at the moment. Cheers, Omar -- 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] API Access through proxy
Hi, While posting the Messages on the mapped user wall we are getting below show error The remote name could not be resolved: 'api.twitter.com' Please advice us to over come this issue. -- 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] how to get the tweet which has hightest retweet count
Hi guys, I want to get a tweet which has the highest retweet count number during the last five minutes. Does the api support this? if not support, is there a plan to support it in the future? thanks, Journey -- 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] filter qustionable content
hi guys, does any can give me a guideline of how does Twitter handle this filtering - Spam, obscenity, questionable content, etc. After go through the api, i didn't find any information about it. does that means twitter does not do any filter for obscenity,questionable content? thanks, Journey -- 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] Encrypting/masking certain keywords while tweeting on Twitter site
Hello, I need one help regarding encryption or masking certain keywords when a user accidently keys in sensitive information e.g. SSN (XXX-yy-) to anyone (as opposed to DM) which gets displayed on the time line e.g. i tweet as per @jigsb my SSN # is XXX-yy-. When it gets displayed on the time line, it should look like - @jigsb my SSN # is ***-**- I guess, the detection of pattern should not be an issue (using RegEx), but does Twitter website gives you an interface to detect such pattern and take actions accordingly Appreciate your help in this regard ~Jigs -- 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] filter qustionable content
No, twitter doesn't filter any tweets text. Low quality users will be excluded from search results. On 18 May 2011, at 07:17, journey wrote: hi guys, does any can give me a guideline of how does Twitter handle this filtering - Spam, obscenity, questionable content, etc. After go through the api, i didn't find any information about it. does that means twitter does not do any filter for obscenity,questionable content? thanks, Journey -- 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 -- Scott Wilcox @dordotky | sc...@dor.ky | http://dor.ky +44 (0) 7538 842418 | +1 (646) 827-0580 -- 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] Twitter Search Widget on iPad
Hi All, I recently launched this website: http://makesmyjobeasy.com I have had a few people tell me that the scroll bar visible on the right of the twitter search widget used to move the tweets up and down so you can see the rest doesnt appear on the Safari iPad2 browser (unsure about ipad1). Anyone shed some light onto why or is this just standard?!?! Thanks, Phil -- 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] ToS and programatical follow
Hi I'm working on a website how expose interesting things about cooking and food. We have created a service how use the stream API to get information about people on twitter talking about our subject of interest. In our website, if our administrator thinks that content is good enough, he mark the twitter account as interesting and we look for his tweets with Stream API. I want to tell that it is a manual action for our admin. But we have now the idea to follow this twitter users talking about food with our account ( 1 account ), the one that we have marked as interressing, but in reading carefully the ToS Twitter says we cannot auto-follow twitter account. As we don't want to auto-follow but follow programaticaly, principaly to avoid annoying repetitive task like : mark it as interressing in our website back office then go on twitter to follow them, I'd like to ask you if it is permited to programaticaly follow people like we want to do ? Best regards and thank you in advance. -- 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: Visual refresh of the OAuth screens
Matt, what happened to the mobile version of these new OAuth screens? Is there no mobile version at all? There used to be automatic mobile detection (based on user agent) and rendering of mobile friendly screens: http://mashable.com/2010/02/03/twitter-oauth-mobile/ This all stopped working when you rolled out the new OAuth screens. There seems to be only one version. The new screens work OK on most touch phones, but are unusable in feature phones and most non-touch smartphones with smaller displays: * The new screens are actually too heavy for a lot of basic mobile browsers and end up crashing them (for starters, most of our Nokia phones crash) * Other phones simply can't scroll or click on the buttons as the browser gets incredibly slow or freezes (older Samsung, LG phones) * On the phones where the browser doesn't crash or freeze, the user can't even see most of the text/info about the app (which was the whole point of the new screens) If there a way to get a mobile version of this page? Any workaround? Any way to get the old mobile screens at least temporarily? Or can you _really_ simplify the OAuth screens so that they work with very basic mobile browsers. We have a lot of angry users that paid for one of our twitter apps and now can't sign-in because of your new OAuth screens. Not everyone is using iPhone/Android in this world. Please tell us that there is a way for feature phones to use OAuth. -- 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] Twitter Streaming API blocked user
Hi Fabien, The Streaming API/Site Streams/User Streams don't support certain kinds of post-filter user settings like blocked users/no retweets from this user/etc. -- if you want to provide that filtering, you can keep an index of the users they block and filter in real time. http://dev.twitter.com/doc/get/blocks/blocking/ids to get the ids. @episod http://twitter.com/episod - Taylor Singletary On Tue, May 17, 2011 at 11:33 PM, Fabien Penso fabienpe...@gmail.comwrote: Hi, I'm using the streaming API (sitestream) and one of my user @thecivvie blocked @fabientest but if @fabientest tweets, I see those tweets for @thecivvie coming. Is that an implementation bug, is it supposed to be like this, or have I missed something? Thanks. -- 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] ToS and programatical follow
For a case of single-account use like this, you're totally fine using the API to programmatically follow. Most of the terms around automated following are clarified here: http://support.twitter.com/entries/76915-automation-rules-and-best-practiceswith some more general information on the limits of following here: http://support.twitter.com/articles/68916-following-rules-and-best-practices Avoid follow-churn: don't follow then unfollow, then refollow. Keep your following rate reasonable -- though you're programmatically following you should still throttle your actions to a polite rate, especially if you're planning on a larger number of follow actions. Finally, make sure you're using an account with a bio and a picture, maybe even some tweets. A generic looking account that follows a bunch of users but has no followers or tweets or identity itself is likely to be reported as spam. @episod http://twitter.com/episod - Taylor Singletary On Wed, May 18, 2011 at 5:32 AM, boblefrag boblef...@gmail.com wrote: Hi I'm working on a website how expose interesting things about cooking and food. We have created a service how use the stream API to get information about people on twitter talking about our subject of interest. In our website, if our administrator thinks that content is good enough, he mark the twitter account as interesting and we look for his tweets with Stream API. I want to tell that it is a manual action for our admin. But we have now the idea to follow this twitter users talking about food with our account ( 1 account ), the one that we have marked as interressing, but in reading carefully the ToS Twitter says we cannot auto-follow twitter account. As we don't want to auto-follow but follow programaticaly, principaly to avoid annoying repetitive task like : mark it as interressing in our website back office then go on twitter to follow them, I'd like to ask you if it is permited to programaticaly follow people like we want to do ? Best regards and thank you in advance. -- 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: Auto Populating Tweets Broken?
Hi Omar, Sorry for the confusion -- we recommend Web Intents as we've developed the Tweet Intent specifically for this purpose -- let us know what tweaks you think the display needs to look good in a full browser tab. Intents are optimized to load quickly and service the user's intent as efficiently as possible -- the old way requires a more significant load time and invites the user to engage in all kinds of other fun Twitter activity aside from tweeting -- maybe they'll even forget why you sent them there in the first place. This is a bug and while I don't have an ETA on when it will be fixed, it was not intentional and this old hack has not been deprecated. @episod http://twitter.com/episod - Taylor Singletary On Tue, May 17, 2011 at 5:34 PM, omegdadi omegd...@gmail.com wrote: Hey There, +1. This issue is affecting all of our products at the moment. I can't find any notification anywhere about this being deprecated today. Please restore this functionality. And allow us some time to migrate w/ a date in mind. If it's no longer going to be supported, we need to know sooner as we have clients waiting for an answer at the moment. We would like to use intents, but we need a full page to send the user to since we can't always open a popup window (ie from Flash.) and that page doesn't look good in a full browser tab. Thanks, Omar On May 17, 3:05 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Yahel, Meet Web Intents:http://dev.twitter.com/pages/intents(take a look on the intent/tweet intent). It really is super easy to implement. For example:http://twitter.com/intent/tweet?text=foobar Arnaud / @rno http://twitter.com/rno On Tue, May 17, 2011 at 1:18 PM, Yahel Carmon yah...@gmail.com wrote: Hey, We've just noticed that auto-populating tweets using http://twitter.com/home/?status=foobarno longer works. Has this feature been totally removed, or is this a temporary glitch? (Perversely,http://twitter.com/?status=foobarworks, but that was the older method that broke last year and we were told to add /home to fix it.) I know we're supposed to move to the official Tweet button, but we have a very large scale CRM that still relies on the old method. Please let me know ASAP, as we have a lot of broken tweet links in the wild. Thanks, Yahel -- Yahel Carmon (917) 445-3498 Twitter:http://twitter.com/yahelc Facebook:http://facebook.com/yahel LinkedIn:http://www.linkedin.com/in/yahelc -- 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
Re: [twitter-dev] how to get the tweet which has hightest retweet count
Hey Journey, There is no dedicated API method to retrieve the most retweeted tweet in a given time window. However, every status object comes with a retweet_count attribute that you can for example use to curate the most retweeted tweets of a timeline, a list... Hope that helps! Arnaud / @rno On May 18, 2011, at 7:18 AM, journey yinmathema...@gmail.com wrote: Hi guys, I want to get a tweet which has the highest retweet count number during the last five minutes. Does the api support this? if not support, is there a plan to support it in the future? thanks, Journey -- 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
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] Twitter Streaming API blocked user
Thanks Taylor, I wish the streaming did, is that planned at all in the future? Don't want to code something if you guys are planning it soon :) On Wed, May 18, 2011 at 7:30 AM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Fabien, The Streaming API/Site Streams/User Streams don't support certain kinds of post-filter user settings like blocked users/no retweets from this user/etc. -- if you want to provide that filtering, you can keep an index of the users they block and filter in real time. http://dev.twitter.com/doc/get/blocks/blocking/ids to get the ids. @episod - Taylor Singletary On Tue, May 17, 2011 at 11:33 PM, Fabien Penso fabienpe...@gmail.com wrote: Hi, I'm using the streaming API (sitestream) and one of my user @thecivvie blocked @fabientest but if @fabientest tweets, I see those tweets for @thecivvie coming. Is that an implementation bug, is it supposed to be like this, or have I missed something? Thanks. -- 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: A new permission level
We know this will take some time so we are allowing a transition period until the end of this month. This is such a short timeframe for people to rebuild, QA and resubmit their apps that it will certainly mean some peoples apps will stop working while they are waiting for them to be 'approved' by their own QA, or their internal IT department, or their app store or market. I would request that you think about extending it. Angus -- 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] Twitter Streaming API blocked user
Another one : It would be nice to have those events in the stream (new blocked user / removal of a blocked user) so we don't need to fetch those through the REST API once our streaming process is running. On Wed, May 18, 2011 at 10:27 AM, Fabien Penso fabienpe...@gmail.com wrote: Thanks Taylor, I wish the streaming did, is that planned at all in the future? Don't want to code something if you guys are planning it soon :) On Wed, May 18, 2011 at 7:30 AM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Fabien, The Streaming API/Site Streams/User Streams don't support certain kinds of post-filter user settings like blocked users/no retweets from this user/etc. -- if you want to provide that filtering, you can keep an index of the users they block and filter in real time. http://dev.twitter.com/doc/get/blocks/blocking/ids to get the ids. @episod - Taylor Singletary On Tue, May 17, 2011 at 11:33 PM, Fabien Penso fabienpe...@gmail.com wrote: Hi, I'm using the streaming API (sitestream) and one of my user @thecivvie blocked @fabientest but if @fabientest tweets, I see those tweets for @thecivvie coming. Is that an implementation bug, is it supposed to be like this, or have I missed something? Thanks. -- 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
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
[twitter-dev] Re: A new permission level
Hi Matt,
can you please give us more time to adapt to this. It is impossible to
make the appropriate changes and submit to appstore within this
timeframe.
Thanks,
Ole, Gravity Twitter Client for Symbian
On May 18, 7:01 pm, Matt Harris thematthar...@twitter.com 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 onhttps://dev.twitter.com/appsand 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
tohttps://api.twitter.com/1/direct_messages/sent.jsonwill 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-dev] Re: A new permission level
Matt, If I understand correctly, activate the new permission, all Read and Read/Write user_tokens issued to third-party applications will lose their ability to read direct messages. That is a HUGE and MAJOR headache for existing apps and their thousands of users who are currently using any of the /1/ direct_messages methods. Can't you rather grand-father in apps and user_tokens that have already been granted? -- 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
--
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
[twitter-dev] Re: A new permission level
Matt, Ultimately I understand the issues with xAuth and granularity. Frankly, if you just ditched xAuth entirely, I can see decent arguments for it. However, we've made a significant investment in the xAuth UX. If we have to change it, 13 days is simply not sufficient for most devs. It will be a stretch for Spaz, given that we are all volunteer and do it in our spare time. Folks who have to deal with app store submissions and the like are even more under the thumb. 2 months, I think is much more reasonable. In addition, real effort being put forth by the dev relations team to show how to migrate to a solid oAuth flow on desktop and mobile would be very useful to many devs. Good luck. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com -- 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: A new permission level
Hi Matt, I understand the change need to happen. In regards to xAuth though and finding an upgrade path, the assumption is that those that got access to that were developing desktop/mobile clients (not centralized services) so there is no centralized storage of tokens or user data (only in standalone applications in those applications). In a good number of the high profile applications of xAuth, it's an actual client (like TweetBot, Seesmic, Tweetdeck, etc). Those clients almost always interface with direct messages because they replicate most of the twitter features up and down. In that case, can you please reconsider the case of xAuth. Grandfather existing xAuth users to read, write, and direct message level. Then going forward with xAuth, evaluate the need of the app if it needs read/write/direct message on a case by case basis? You are going to break a good number of applications with that change. Although a month is just barely enough time to turn around an update for iOS if developers rush, it doesn't leave a lot of grace time for users that do not upgrade their applications very often. My own stats for my apps show without sending out notifications to nag the users to tell of an update (or force them to an update by sending them to the store when they launch the app), nearly half my users do not upgrade for at least 2 to 3 weeks after an update comes out. I hate to bring up comparisons to facebook, but they give us a good developer roadmap (http://developers.facebook.com/roadmap/ ) with a decent time line for deprecation, ramp downs, and migration paths. Zac -- 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: [twitter-api-announce] A new permission level
Hi Matt,
1. xAuth apps are already approved by you guys and have a (I'm assuming)
higher threshold to get access to. I'd really ask you guys to re-consider and
allow xAuth access to DMs. Or at the very least allow clients to apply for
exceptions to this rule.
2. Under 2 weeks is way too short of a time for this big of a change.
On May 18, 2011, at 12: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 API documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Change your membership to this group:
http://groups.google.com/group/twitter-api-announce?hl=en
---
Paul Haddad
paul.had...@gmail.com, p...@tapbots.com, p...@pth.com
--
Twitter developer
Re: [twitter-dev] Encrypting/masking certain keywords while tweeting on Twitter site
Hi, Jigs, You're probably best off running your regex search and doing any replacing within your own application, before you send the tweets off to Twitter -- once the tweet's been tweeted, there's no way to modify it. You could probably follow your users, search for suspicious tweets, delete them (provided your users have authenticated your app), and possibly re-send censored copies -- in general, this sounds like a pretty annoying feature, deleting tweets and re-sending near-duplicates (especially for the people following your users), but if you've got a very paranoid user base, they may think an obnoxious tweet-delete-retweet cycle is worth it to protect their data? Good luck, -Alex On Wed, May 18, 2011 at 12:08 AM, jigneshbh jigs.bh...@gmail.com wrote: Hello, I need one help regarding encryption or masking certain keywords when a user accidently keys in sensitive information e.g. SSN (XXX-yy-) to anyone (as opposed to DM) which gets displayed on the time line e.g. i tweet as per @jigsb my SSN # is XXX-yy-. When it gets displayed on the time line, it should look like - @jigsb my SSN # is ***-**- I guess, the detection of pattern should not be an issue (using RegEx), but does Twitter website gives you an interface to detect such pattern and take actions accordingly Appreciate your help in this regard ~Jigs -- 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 -- Alex Feinberg CTO, Trak.ly http://trak.ly/ -- 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: A new permission level
I very much agree. To get xAuth, we all had to apply and undergo some
sort of verification process.
Also, if I take my app Gravity as an example, I am using xAuth (and
previously Basic Auth) since the very beginning and there have been
zero complaints from users that Gravity has been misusing the DM
feature.
Why? Well, it can't. It's a standalone, mobile application and not a
web app. I, as the author, do not have access to the users passwords
nor to their oAuth tokens.
Furthermore, Gravity is a client on the Symbian platform where you
cannot open the webbrowser for the OAuth flow on many phone models.
And there is no official client on the Symbian platform (although it
would be nice if it was Gravity :-))
Could you please re-consider this and either grandfather xauth clients
or offer a checkbox on the user's Twitter.com settings for the xAuth
clients where they can manually disable/enable DMs?
Wouldn't that be a very good decision for all xAuth clients anyway?
Just add a checkbox so the users can disable DMs if they really don't
want DMs in their mobile/etc. third party clients.
As a side note, the time to get an app through the OviStore (Nokia's
App Store) process can be quite long. I don't think 13 days will be
enough for this.
Cheers
Ole (@janole / @gravityapp)
On May 18, 7:49 pm, Paul Haddad paul.had...@gmail.com wrote:
Hi Matt,
1. xAuth apps are already approved by you guys and have a (I'm assuming)
higher threshold to get access to. I'd really ask you guys to re-consider and
allow xAuth access to DMs. Or at the very least allow clients to apply for
exceptions to this rule.
2. Under 2 weeks is way too short of a time for this big of a change.
On May 18, 2011, at 12: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 onhttps://dev.twitter.com/appsand 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
[twitter-dev] Re: A new permission level
Hello. For my app, it's inconvenient that the DM permission is only available lumped in with the write permission, because now I have to request both even though my app has no facility for posting (it's a notification-only app), and I expect users will (rightly) be suspicious about that. Also on the subject of granularity, it would be great if the app could request DM access but make it optional, such that users can turn it off on the authorization page. If the user declines it then the app would be able to ask them to reauthorize if they later try to use the DM feature of the app. Thank you. - Jon -- 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: A new permission level
I had most of the same thoughts already mentioned in this thread so wont reiterate everyone, except to add that this seems like a rather sudden and disruptive change coming just after #devnestsf where Twitter made a point that it was trying to provide better guidance so companies that rely on the platform have time to plan and make changes. @knight9 -- 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: A new permission level
Hello, There have been a lot of opinions voiced about how this is being implemented. This not only proves troublesome for xAuth clients, but it lends me to worry about how the future of permissions will evolve. Effectively now, every single Twitter user needs to get their application re-authed for the new tokens to provide DM access by the end of the month. The Facebook style of using a 'scope' for individual permissions is so much more viable. I also believe that the API should provide a lookup for the permissions that a set of credentials currently provides. I honestly believe that going down the 'scope' route for permissions will be a lot better for all concerned. When new permissions are introduced to the API in the future, it would be a small matter of updating the requesting scope for the application developer, rather than completely rewriting chunks of code. I'd like a response from Matt, Taylor or Raffi on this matter and the plans for future permissions and their implementation. On 18 May 2011, at 19:42, Naveen wrote: I had most of the same thoughts already mentioned in this thread so wont reiterate everyone, except to add that this seems like a rather sudden and disruptive change coming just after #devnestsf where Twitter made a point that it was trying to provide better guidance so companies that rely on the platform have time to plan and make changes. @knight9 -- 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 -- Scott Wilcox @dordotky | sc...@dor.ky | http://dor.ky +44 (0) 7538 842418 | +1 (646) 827-0580 -- 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] Unwanted Link Shortening with t.co
Since switching to the new Intents linking, by URLs are being shortened. I have a registered Twitter application, and a relatively short URL already ( http://TagsBy.me ). I'd like to continue using my own URLs, even if it means I have to build a shortener with an even shorter domain. However, I'd like to know what the rules/guidelines are that Twitter uses for overriding links, since there are many exceptions that I see in my Twitter stream. -- 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: A new permission level
I agree with Scott. A token should simply be a bond between the user and the app, it should not contain any knowledge of permissions/restrictions. A token simply represents Hi, I'm making a call on behalf of Joe User. Attached is the request I want to make. Make sure I'm allowed to do this before you execute it. Forcing re-authentication whenever permissions change is a major pain for both developers and users. Removing permission-based tokens benefits the user because they can modify the access an application has without having to re-authenticate, something 99% of users will not understand. On Wed, May 18, 2011 at 11:51 AM, Scott Wilcox sc...@dor.ky wrote: Hello, There have been a lot of opinions voiced about how this is being implemented. This not only proves troublesome for xAuth clients, but it lends me to worry about how the future of permissions will evolve. Effectively now, every single Twitter user needs to get their application re-authed for the new tokens to provide DM access by the end of the month. The Facebook style of using a 'scope' for individual permissions is so much more viable. I also believe that the API should provide a lookup for the permissions that a set of credentials currently provides. I honestly believe that going down the 'scope' route for permissions will be a lot better for all concerned. When new permissions are introduced to the API in the future, it would be a small matter of updating the requesting scope for the application developer, rather than completely rewriting chunks of code. I'd like a response from Matt, Taylor or Raffi on this matter and the plans for future permissions and their implementation. On 18 May 2011, at 19:42, Naveen wrote: I had most of the same thoughts already mentioned in this thread so wont reiterate everyone, except to add that this seems like a rather sudden and disruptive change coming just after #devnestsf where Twitter made a point that it was trying to provide better guidance so companies that rely on the platform have time to plan and make changes. @knight9 -- 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 -- Scott Wilcox @dordotky | sc...@dor.ky | http://dor.ky +44 (0) 7538 842418 | +1 (646) 827-0580 -- 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: A new permission level
On Wed, May 18, 2011 at 12:50:30PM -0700, Derek Gathright wrote: I agree with Scott. A token should simply be a bond between the user and the app, it should not contain any knowledge of permissions/restrictions. A token simply represents Hi, I'm making a call on behalf of Joe User. Attached is the request I want to make. Make sure I'm allowed to do this before you execute it. Forcing re-authentication whenever permissions change is a major pain for both developers and users. Removing permission-based tokens benefits the user because they can modify the access an application has without having to re-authenticate, something 99% of users will not understand. +1 -- Martin Dapas -- 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] Problem getting request tokens on REST API
As of yesterday, May 17, I've been unable to get request tokens to login via the API for my web-based Twitter client. Now, whenever I try to get a request token, I get a 401 HTTP code, Failed to validate oauth signature and token The url in question: https://timshomepage.net/twitter/login The app is called Tim's Home Page I've tried resetting the API keys, made sure all the API urls were pointing to the correct locations, and still haven't been able to fix the problem. Normally, I'm able to connect either through an @anywhere bridge code, or directly using the REST api. I'm using the TwitterOauth library, and that calls to https://api.twitter.com/oauth/request_token I know the bridge code isn't supported, but that's a secondary issue at this point. Also, I was able to connect reliably prior to May 17. I hadn't changed any of my login code when I started having the issue. These are the headers of the response: [http_header] = Array ( [date] = Wed, 18 May 2011 19:48:44 GMT [server] = hi [status] = 401 Unauthorized [x_transaction] = 1305748124-55771-54144 [x_frame_options] = SAMEORIGIN [last_modified] = Wed, 18 May 2011 19:48:44 GMT [x_runtime] = 0.00721 [content_type] = text/html; charset=utf-8 [content_length] = 44 [pragma] = no-cache [x_revision] = DEV [expires] = Tue, 31 Mar 1981 05:00:00 GMT [cache_control] = no-cache, no-store, must-revalidate, pre-check=0, post-check=0 [x_mid] = 48d06356e9a0e07c6cf92e22490f158add0e21b5 [set_cookie] = _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCJY0pwQwAToHaWQiJWVlNjcyMTBiNzI3MDRm %250AYjkxM2JhMDA1Mzg1OWIwN2YxIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy %250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA-- e54173a833746ed6ab7a99af5fae672a63223f55; domain=.twitter.com; path=/; HttpOnly [vary] = Accept-Encoding ) The body of the response is Failed to validate oauth signature and token. To get the response, I'm using the TwitterOauth library, which accesses this url via a GET request: https://api.twitter.com/oauth/request_token?oauth_callback=https%3A%2F%2Ftimshomepage.net%2Ftwitter%2Flogin_auth%2Foauth_consumer_key=qfcMgJ71G10MTElZpxCOwAoauth_nonce=5976da763cfc597a6b10d7f68f2d6d55oauth_signature=7OOMCmTvHbKnrmYVX2m7kbDEkd4%3Doauth_signature_method=HMAC-SHA1oauth_timestamp=1305734876oauth_version=1.0 (Obviously the timestamp sent is different based on the request) -- 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: A new permission level
The more I think about this, the less it makes any sense whatsoever to force everyone through a re-authentication if DM access is required. Here's why: 1) For existing user tokens, the users have already granted access with the knowledge that it is to their DMs as well. In other words, they have already granted access to their DMs. 2) If an app needs access to the users' DMs, it is going to force thousands of people to waste thousands of hours to re-authorize something they want the app to do and something they have already implicitly granted to the app. 3) Many users are going to miss the memo, and then be very upset with the app owner(s) because what had worked before suddenly stopped working. 4) Additional and completely unnecessary workload and costs are going to be added to the support staff of the app, to help users who do not understand why they need to re-authorize, or who have missed the memo in the first place. 5) By forcing re-authorization for apps that require DM access and already have DM access, Twitter gains absolutely nothing. After forcing thousands of people through a redundant process, we're back at where we started, namely, the app has access to the user's DMs. It's not like the user has a choice of not granting a requesting app access to his DMs, but only to his followers and tweets. If the app request DM access, the user can either grant it, or deny access completely. Exactly the same way it works today. The only benefit here is for apps who don't need DM access, which will now be able to request account access without DM access. But, if the app does not need or use access to DMs, it provides absolutely no benefit to take existing DM access of already granted user tokens away. It is not used. It makes perfect sense to implement this change from a date going forward, meaning all user tokens granted after that date will be either Read, Read Write, or Read Write DM. That provides more transparency for the user. But to yank away existing access rights and then force the equivalent of a small nation through a re- authentication process just to re-establish what had already been granted and then unilaterally taken away, that makes no sense at all. -- 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: A new permission level
On Wed, May 18, 2011 at 11:37 AM, Jon Colverson jjc1...@gmail.com wrote: Also on the subject of granularity, it would be great if the app could request DM access but make it optional, such that users can turn it off on the authorization page. If the user declines it then the app would be able to ask them to reauthorize if they later try to use the DM feature of the app. Agreed. I'm really disappointed with this change. Asking users to reauthorize is a burden on both developers and users. Existing users already gave their permission for apps to access private messages. The lead time for developers to respond to this change is ridiculously short. In my opinion, Twitter should have allowed users finer grained control over permissions, allowing them to selectively remove private message permissions for existing apps. An app should be able to request a set of default permissions. Users should be able to accept the defaults, or selectively deny individual permissions. If an app has optional private message features, it must request private message permission from *all* users. Either that or register multiple apps for each set of appropriate permissions, which is confusing and difficult for users and developers to manage. Is it too late to re-think this, Twitter? -Marc -- 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] Problem getting request tokens on REST API
thats because it was my birthday From: timw4mail timw4m...@gmail.com To: Twitter Development Talk twitter-development-talk@googlegroups.com Sent: Wednesday, 18 May, 2011 21:10:31 Subject: [twitter-dev] Problem getting request tokens on REST API As of yesterday, May 17, I've been unable to get request tokens to login via the API for my web-based Twitter client. Now, whenever I try to get a request token, I get a 401 HTTP code, Failed to validate oauth signature and token The url in question: https://timshomepage.net/twitter/login The app is called Tim's Home Page I've tried resetting the API keys, made sure all the API urls were pointing to the correct locations, and still haven't been able to fix the problem. Normally, I'm able to connect either through an @anywhere bridge code, or directly using the REST api. I'm using the TwitterOauth library, and that calls to https://api.twitter.com/oauth/request_token I know the bridge code isn't supported, but that's a secondary issue at this point. Also, I was able to connect reliably prior to May 17. I hadn't changed any of my login code when I started having the issue. These are the headers of the response: [http_header] = Array ( [date] = Wed, 18 May 2011 19:48:44 GMT [server] = hi [status] = 401 Unauthorized [x_transaction] = 1305748124-55771-54144 [x_frame_options] = SAMEORIGIN [last_modified] = Wed, 18 May 2011 19:48:44 GMT [x_runtime] = 0.00721 [content_type] = text/html; charset=utf-8 [content_length] = 44 [pragma] = no-cache [x_revision] = DEV [expires] = Tue, 31 Mar 1981 05:00:00 GMT [cache_control] = no-cache, no-store, must-revalidate, pre-check=0, post-check=0 [x_mid] = 48d06356e9a0e07c6cf92e22490f158add0e21b5 [set_cookie] = _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCJY0pwQwAToHaWQiJWVlNjcyMTBiNzI3MDRm %250AYjkxM2JhMDA1Mzg1OWIwN2YxIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy %250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA-- e54173a833746ed6ab7a99af5fae672a63223f55; domain=.twitter.com; path=/; HttpOnly [vary] = Accept-Encoding ) The body of the response is Failed to validate oauth signature and token. To get the response, I'm using the TwitterOauth library, which accesses this url via a GET request: https://api.twitter.com/oauth/request_token?oauth_callback=https%3A%2F%2Ftimshomepage.net%2Ftwitter%2Flogin_auth%2Foauth_consumer_key=qfcMgJ71G10MTElZpxCOwAoauth_nonce=5976da763cfc597a6b10d7f68f2d6d55oauth_signature=7OOMCmTvHbKnrmYVX2m7kbDEkd4%3Doauth_signature_method=HMAC-SHA1oauth_timestamp=1305734876oauth_version=1.0 (Obviously the timestamp sent is different based on the request) -- 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: A new permission level
Quick question and a comment.
1) I see the new Default Access type as Read, Write Private
Message not Read, Write Direct Messages. Is there a typo
somewhere?.
2) I just have to agree with everyone here that having all of our
users re-auth our app to give them access to a feature they've already
agreed to as being a pretty poor implementation of this change. The
vast majority of users will not understand why and/or what they need
to re-auth and the ones that don't will be swamping our support people
on June 1st when they no longer see their Direct Mentions. If there
is any way to grandfather in existing users who have already
authorized access to their direct messages that would be a huge help
for every company using twitter in their apps.
Thanks,
Becca
On May 18, 10:01 am, Matt Harris thematthar...@twitter.com 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 onhttps://dev.twitter.com/appsand 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
tohttps://api.twitter.com/1/direct_messages/sent.jsonwill 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
[twitter-dev] Tweet button URL accepted chars
Hi, I'm trying to put a tweet button in a Spanish site, but when the URL being sent has accents in it (for example, using an á char -%E1-), I get a Malformed URI sequence error. I've tried the button and it works for every other case. Is there anything I can do about this? Thanks! Micaela. -- 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: Twitter Streaming API blocked user
I agree this nice idea. On 5月19日, 午前2:30, Fabien Penso fabienpe...@gmail.com wrote: Another one : It would be nice to have those events in the stream (new blocked user / removal of a blocked user) so we don't need to fetch those through the REST API once our streaming process is running. On Wed, May 18, 2011 at 10:27 AM, Fabien Penso fabienpe...@gmail.com wrote: Thanks Taylor, I wish the streaming did, is that planned at all in the future? Don't want to code something if you guys are planning it soon :) On Wed, May 18, 2011 at 7:30 AM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Fabien, The Streaming API/Site Streams/User Streams don't support certain kinds of post-filter user settings like blocked users/no retweets from this user/etc. -- if you want to provide that filtering, you can keep an index of the users they block and filter in real time. http://dev.twitter.com/doc/get/blocks/blocking/idsto get the ids. @episod - Taylor Singletary On Tue, May 17, 2011 at 11:33 PM, Fabien Penso fabienpe...@gmail.com wrote: Hi, I'm using the streaming API (sitestream) and one of my user @thecivvie blocked @fabientest but if @fabientest tweets, I see those tweets for @thecivvie coming. Is that an implementation bug, is it supposed to be like this, or have I missed something? Thanks. -- 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
Re: [twitter-dev] Re: A new permission level
Aside from all the emotional/philosophical stuff in this thread, I am concerned about a major possible bug: I have updated my apps to use Read/Write/DM permissions, and then it saves it as Read-Only... I tried to change it back to just Read/Write, and again it is saved as Read-Only. Is anyone else having this problem? Users are going insane... -Chad -- 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: A new permission level
nevermind, i must have been out of the loop.. i was using the old form so use http://dev.twitter.com/apps and DO NOT USE http://twitter.com/apps (which, should be deleted or auto-forwarded or something) caramba, -chad On Wed, May 18, 2011 at 3:47 PM, Chad Etzel jazzyc...@gmail.com wrote: Aside from all the emotional/philosophical stuff in this thread, I am concerned about a major possible bug: I have updated my apps to use Read/Write/DM permissions, and then it saves it as Read-Only... I tried to change it back to just Read/Write, and again it is saved as Read-Only. Is anyone else having this problem? Users are going insane... -Chad -- 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: Devnest Recap
Hello Jason and other folks that made it to #devnestSF, I did not make it out. I had one huge question and I wonder if any of the other folks had it: When (if ever) will twitter open up embedding in the details pane to new companies? (specifically video players) Did anyone else ask this? What is the answer? Thank you very much, BB On May 17, 12:58 pm, Jason Costa jasonco...@twitter.com wrote: Hi everyone, Thanks again to those of you who spent the evening with us this past Thursday at #devnestSF. We had a great time seeing so many of you, and hope you enjoyed yourselves too. We started off the night with talks from Dick Costolo and Ryan Sarver, then saw presentations from four great companies in the ecosystem: DataMinr, Klout, The Guardian, and Quora. A big thanks to all four of them for coming out. We also had a chance to do QA with Ryan and Matt Harris from the Platform team. We heard some solid questions from the audience around an OAuth 2 implementation, the status of the JavaScript API and @anywhere, opening up an API for the t.co shortener, and more. We’re hoping to eventually upload videos from the event, but don’t have a timeline as of yet for that. Just to recap on some of the statistics we revealed during the event: - the platform now receives 13 Billion API requests a day - 600,000 developers are working with the Twitter API - 900,000 applications have integrated with the Twitter API Additionally, we saw other exciting activities in the ecosystem over the past six months: - ~$1 Billion in acquisitions - ~$475 Million in venture capital investment As I mentioned above, we had some great ecosystem company presentations too: - DataMinr sent out an alert regarding Osama Bin Laden’s death 20 minutes before Bloomberg reported it, and the detection was based on only 19 tweets. - Klout is now serving almost 1 Billion API calls monthly, with more than 4 billion graph edges scored daily and over 6 billion tweets analyzed for user topics every three months. - Guardian discussed how they were able to pull down a massive volume of tweets, and analyze public sentiment around Tony Blair at the Chilcott Inquiry. - Quora illustrated how they effectively use the Twitter OAuth sign-in flow, and noted how they see an average of 30 click-throughs when a user tweets an answer out. If you attended the event and have feedback, please feel free to send me a note (jasonco...@twitter.com) - I’d love to hear how you felt about it. We want to do more of these in the future, and your feedback will help us to better calibrate those events. -- 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] embed a video player in the Details pane
Does anyone know when (if ever) twitter will open up the details pane to new companies? Thanks, BB -- 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: A new permission level
Matt, This maybe a harder architectural shift, but a better solution would be to move permissions from being per application, but instead a per authentication token method, wherein that each token stores the permissions that the app requested and was granted at the time they authorized. So in this case, let us pass in a well know list of fine grain permissions we want/need when we make an oAuth request and then offer an end point to authorize for additional permissions when needed to upgrade a token's access in the future as new features come out. In the case of xAuth, doing this wouldn't be as disruptive as all existing tokens would have all the permissions they intended when they were requested. In that xAuth could have a default permission level as set by Twitter when someone requests access to xAuth. Zac -- 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: A new permission level
Please exclude xAuth mobile clients from this, logically and from the usability point of view, it doesn't make any sense, the user authorize my app to use his account, why i ask for his authorization again to view his Direct messages, why you insist on making our life very hard :( -- 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] embed a video player in the Details pane
Hi BB, We're not accepting any new applications for the details pane at the moment. Should this change we will let everyone know. Best @themattharris Developer Advocate, Twitter http://twitter.com/themattharris On Wed, May 18, 2011 at 4:02 PM, BB thebar...@gmail.com wrote: Does anyone know when (if ever) twitter will open up the details pane to new companies? Thanks, BB -- 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
[twitter-dev] Re: embed a video player in the Details pane
Matt, Thank you very much for the prompt reply. 2 follow ups though: Do you ever foresee this happening? And if so do you have an approximate time-frame? Or if you tell me would you have to kill me? :-) Thanks, BB On May 18, 4:54 pm, Matt Harris thematthar...@twitter.com wrote: Hi BB, We're not accepting any new applications for the details pane at the moment. Should this change we will let everyone know. Best @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 18, 2011 at 4:02 PM, BB thebar...@gmail.com wrote: Does anyone know when (if ever) twitter will open up the details pane to new companies? Thanks, BB -- 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: A new permission level
Hey everyone, Thank you for all the feedback on the list, email and through Tweets. We've been responding throughout the day to many of the Tweets but wanted to group the questions together and respond here as well. Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension. We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline by two weeks. This means we'll enforce the new permission the week beginning the 14th June 2011. This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store. 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. Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. What if the client using xAuth has no browser and therefore cannot go through OAuth? For single user applications and scripts we provide the 'My Access Token' page of the application details. To ensure the 'My Access Token' is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the 'My Access Token' will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages. When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages? Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn't authorised as for R/W/DM. What if I want to request a different level of access for my application instead of the one my application is registered with? You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages. More information on this method is in our developer documentation: http://dev.twitter.com/doc/post/oauth/request_token Why are permissions attached to the user token? Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize? The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested. We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer. 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-dev] Re: Devnest Recap
Hi BB - it looks like Matt has answered this question in another thread: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/6b37774d6db29b9 Thanks, @jasoncosta On May 18, 3:46 pm, BB thebar...@gmail.com wrote: Hello Jason and other folks that made it to #devnestSF, I did not make it out. I had one huge question and I wonder if any of the other folks had it: When (if ever) will twitter open up embedding in the details pane to new companies? (specifically video players) Did anyone else ask this? What is the answer? Thank you very much, BB On May 17, 12:58 pm, Jason Costa jasonco...@twitter.com wrote: Hi everyone, Thanks again to those of you who spent the evening with us this past Thursday at #devnestSF. We had a great time seeing so many of you, and hope you enjoyed yourselves too. We started off the night with talks from Dick Costolo and Ryan Sarver, then saw presentations from four great companies in the ecosystem: DataMinr, Klout, The Guardian, and Quora. A big thanks to all four of them for coming out. We also had a chance to do QA with Ryan and Matt Harris from the Platform team. We heard some solid questions from the audience around an OAuth 2 implementation, the status of the JavaScript API and @anywhere, opening up an API for the t.co shortener, and more. We’re hoping to eventually upload videos from the event, but don’t have a timeline as of yet for that. Just to recap on some of the statistics we revealed during the event: - the platform now receives 13 Billion API requests a day - 600,000 developers are working with the Twitter API - 900,000 applications have integrated with the Twitter API Additionally, we saw other exciting activities in the ecosystem over the past six months: - ~$1 Billion in acquisitions - ~$475 Million in venture capital investment As I mentioned above, we had some great ecosystem company presentations too: - DataMinr sent out an alert regarding Osama Bin Laden’s death 20 minutes before Bloomberg reported it, and the detection was based on only 19 tweets. - Klout is now serving almost 1 Billion API calls monthly, with more than 4 billion graph edges scored daily and over 6 billion tweets analyzed for user topics every three months. - Guardian discussed how they were able to pull down a massive volume of tweets, and analyze public sentiment around Tony Blair at the Chilcott Inquiry. - Quora illustrated how they effectively use the Twitter OAuth sign-in flow, and noted how they see an average of 30 click-throughs when a user tweets an answer out. If you attended the event and have feedback, please feel free to send me a note (jasonco...@twitter.com) - I’d love to hear how you felt about it. We want to do more of these in the future, and your feedback will help us to better calibrate those events. -- 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: Unwanted Link Shortening with t.co
Twitter is just wrapping your link in t.co. When it gets displayed in Twitter, it will show the link on your domain as you passed it in. On May 18, 12:35 pm, Mo maur...@moluv.com wrote: Since switching to the new Intents linking, by URLs are being shortened. I have a registered Twitter application, and a relatively short URL already (http://TagsBy.me). I'd like to continue using my own URLs, even if it means I have to build a shortener with an even shorter domain. However, I'd like to know what the rules/guidelines are that Twitter uses for overriding links, since there are many exceptions that I see in my Twitter stream. -- 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: A new permission level
Thanks Matt! I still urge you to reconsider the mass breakage of older and existing apps and the crippling mobile/desktop user experiences apps going forward. My own judgement is that yes, maybe user didn't realize that didn't want to give that level of access and matbe the web flow can help twitter communicate to the user better, but it's going up against all the issues of users that already authorized and throws away all the constant re-hashing of the issues that drove the development of xAuth in the first place. I fear it's going to be litteral countdown until doomsday and hell is going to break out of users and developers that didn't get the memo. Zac -- 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: Auto Populating Tweets Broken?
I'm totally with you guys on the value of switching to web intents, and we recommend all our customers doing new implementations use them. However, there are just too many legacy implementations against the old hack, as Taylor deemed it, for you to expect everyone to switch over in such a timeframe. For a very long time the /?status= method was the only way to tweet from a website and web intents are only a few months old, so I hope you guys don't diminish the priority of fixing this bug just because you want to force everyone to the new way of doing things. -jonathan On May 18, 7:50 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Omar, Sorry for the confusion -- we recommend Web Intents as we've developed the Tweet Intent specifically for this purpose -- let us know what tweaks you think the display needs to look good in a full browser tab. Intents are optimized to load quickly and service the user's intent as efficiently as possible -- the old way requires a more significant load time and invites the user to engage in all kinds of other fun Twitter activity aside from tweeting -- maybe they'll even forget why you sent them there in the first place. This is a bug and while I don't have an ETA on when it will be fixed, it was not intentional and this old hack has not been deprecated. @episod http://twitter.com/episod - Taylor Singletary On Tue, May 17, 2011 at 5:34 PM, omegdadi omegd...@gmail.com wrote: Hey There, +1. This issue is affecting all of our products at the moment. I can't find any notification anywhere about this being deprecated today. Please restore this functionality. And allow us some time to migrate w/ a date in mind. If it's no longer going to be supported, we need to know sooner as we have clients waiting for an answer at the moment. We would like to use intents, but we need a full page to send the user to since we can't always open a popup window (ie from Flash.) and that page doesn't look good in a full browser tab. Thanks, Omar On May 17, 3:05 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Yahel, Meet Web Intents:http://dev.twitter.com/pages/intents(takea look on the intent/tweet intent). It really is super easy to implement. For example:http://twitter.com/intent/tweet?text=foobar Arnaud / @rno http://twitter.com/rno On Tue, May 17, 2011 at 1:18 PM, Yahel Carmon yah...@gmail.com wrote: Hey, We've just noticed that auto-populating tweets using http://twitter.com/home/?status=foobarnolonger works. Has this feature been totally removed, or is this a temporary glitch? (Perversely,http://twitter.com/?status=foobarworks, but that was the older method that broke last year and we were told to add /home to fix it.) I know we're supposed to move to the official Tweet button, but we have a very large scale CRM that still relies on the old method. Please let me know ASAP, as we have a lot of broken tweet links in the wild. Thanks, Yahel -- Yahel Carmon (917) 445-3498 Twitter:http://twitter.com/yahelc Facebook:http://facebook.com/yahel LinkedIn:http://www.linkedin.com/in/yahelc -- 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
Re: [twitter-dev] Re: embed a video player in the Details pane
Hi BB, I don't have anymore information i'm afraid. All I know is they are not accepting any more applications right now. Best, @themattharris Developer Advocate, Twitter http://twitter.com/themattharris On Wed, May 18, 2011 at 5:10 PM, BB thebar...@gmail.com wrote: Matt, Thank you very much for the prompt reply. 2 follow ups though: Do you ever foresee this happening? And if so do you have an approximate time-frame? Or if you tell me would you have to kill me? :-) Thanks, BB On May 18, 4:54 pm, Matt Harris thematthar...@twitter.com wrote: Hi BB, We're not accepting any new applications for the details pane at the moment. Should this change we will let everyone know. Best @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 18, 2011 at 4:02 PM, BB thebar...@gmail.com wrote: Does anyone know when (if ever) twitter will open up the details pane to new companies? Thanks, BB -- 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: Auto Populating Tweets Broken?
Thanks for the clarification and bug link Matt! I understand how big of a pain supporting this legacy method must be, especially given the fundamental changes in #newtwitter. I just wanted to emphasize how many sites still use this and probably aren't in a position to easily figure out how to fix it. Thanks, -jonathan On May 18, 5:48 pm, Matt Harris thematthar...@twitter.com wrote: Hi Jonathan, This is being investigated by our engineers at the moment. We'll be posting updates to this ticket on our issue tracker: http://code.google.com/p/twitter-api/issues/detail?id=1650 Best, @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 18, 2011 at 5:42 PM, Jonathan Strauss jonat...@awe.sm wrote: I'm totally with you guys on the value of switching to web intents, and we recommend all our customers doing new implementations use them. However, there are just too many legacy implementations against the old hack, as Taylor deemed it, for you to expect everyone to switch over in such a timeframe. For a very long time the /?status= method was the only way to tweet from a website and web intents are only a few months old, so I hope you guys don't diminish the priority of fixing this bug just because you want to force everyone to the new way of doing things. -jonathan On May 18, 7:50 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Omar, Sorry for the confusion -- we recommend Web Intents as we've developed the Tweet Intent specifically for this purpose -- let us know what tweaks you think the display needs to look good in a full browser tab. Intents are optimized to load quickly and service the user's intent as efficiently as possible -- the old way requires a more significant load time and invites the user to engage in all kinds of other fun Twitter activity aside from tweeting -- maybe they'll even forget why you sent them there in the first place. This is a bug and while I don't have an ETA on when it will be fixed, it was not intentional and this old hack has not been deprecated. @episod http://twitter.com/episod - Taylor Singletary On Tue, May 17, 2011 at 5:34 PM, omegdadi omegd...@gmail.com wrote: Hey There, +1. This issue is affecting all of our products at the moment. I can't find any notification anywhere about this being deprecated today. Please restore this functionality. And allow us some time to migrate w/ a date in mind. If it's no longer going to be supported, we need to know sooner as we have clients waiting for an answer at the moment. We would like to use intents, but we need a full page to send the user to since we can't always open a popup window (ie from Flash.) and that page doesn't look good in a full browser tab. Thanks, Omar On May 17, 3:05 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Yahel, Meet Web Intents:http://dev.twitter.com/pages/intents(takealook on the intent/tweet intent). It really is super easy to implement. For example:http://twitter.com/intent/tweet?text=foobar Arnaud / @rno http://twitter.com/rno On Tue, May 17, 2011 at 1:18 PM, Yahel Carmon yah...@gmail.com wrote: Hey, We've just noticed that auto-populating tweets using http://twitter.com/home/?status=foobarnolongerworks. Has this feature been totally removed, or is this a temporary glitch? (Perversely,http://twitter.com/?status=foobarworks, but that was the older method that broke last year and we were told to add /home to fix it.) I know we're supposed to move to the official Tweet button, but we have a very large scale CRM that still relies on the old method. Please let me know ASAP, as we have a lot of broken tweet links in the wild. Thanks, Yahel -- Yahel Carmon (917) 445-3498 Twitter:http://twitter.com/yahelc Facebook:http://facebook.com/yahel LinkedIn:http://www.linkedin.com/in/yahelc -- 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:
[twitter-dev] Re: A new permission level
Thanks Matt, Two important implementation questions that aren't 100% clear from that announcement or any supporting docs at this point; 1) we are also restricting this permission to the OAuth /authorize web flow only To be clear, does this include using the OAuth /authenticate method as well as the /authorize method? 2) The method direct_messages/new is not included the list of affected requests, so sending (writing) DMs does not requires Private Message permission? Regards, James On May 19, 10:11 am, themattharris thematthar...@twitter.com wrote: Hey everyone, Thank you for all the feedback on the list, email and through Tweets. We've been responding throughout the day to many of the Tweets but wanted to group the questions together and respond here as well. Two weeks is not enough time to implement a web OAuth flow and have the app approved. We need an extension. We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline by two weeks. This means we'll enforce the new permission the week beginning the 14th June 2011. This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store. 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. Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. What if the client using xAuth has no browser and therefore cannot go through OAuth? For single user applications and scripts we provide the 'My Access Token' page of the application details. To ensure the 'My Access Token' is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the 'My Access Token' will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages. When you activate the new permission, will all Read and Read/Write user_tokens issued to third-party applications lose their ability to read direct messages? Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn't authorised as for R/W/DM. What if I want to request a different level of access for my application instead of the one my application is registered with? You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages. More information on this method is in our developer documentation: http://dev.twitter.com/doc/post/oauth/request_token Why are permissions attached to the user token? Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. Users already gave their permission for apps to access private messages, why are you making us, and them, reauthorize? The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested. We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer. 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:
[twitter-dev] Re: embed a video player in the Details pane
Matt, Could you Advocate that they do so? :-) Thanks, BB On May 18, 5:45 pm, Matt Harris thematthar...@twitter.com wrote: Hi BB, I don't have anymore information i'm afraid. All I know is they are not accepting any more applications right now. Best, @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 18, 2011 at 5:10 PM, BB thebar...@gmail.com wrote: Matt, Thank you very much for the prompt reply. 2 follow ups though: Do you ever foresee this happening? And if so do you have an approximate time-frame? Or if you tell me would you have to kill me? :-) Thanks, BB On May 18, 4:54 pm, Matt Harris thematthar...@twitter.com wrote: Hi BB, We're not accepting any new applications for the details pane at the moment. Should this change we will let everyone know. Best @themattharris Developer Advocate, Twitterhttp://twitter.com/themattharris On Wed, May 18, 2011 at 4:02 PM, BB thebar...@gmail.com wrote: Does anyone know when (if ever) twitter will open up the details pane to new companies? Thanks, BB -- 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] Incorrect Signature
OK, I spent the last hour searching for incorrect signature posts and did not solve my issue. When trying to post with oAuth I get Incorrect Signature. It works fine if I log in first, my script works perfectly, but if I rely on the oAuth to log me in it does not work, Incorrect Signature. Any ideas? Jay -- 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
