[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] Over the limit for this type of request, please wait a while and try again
Hi folks, Our service has been down for over 3 days now due to broken API calls. Still waiting on any information from Twitter about what's going on, but still in the dark. About 3 days ago we started receiving messages (incorrectly in the new error structure) saying Over the limit for this type of request, please wait a while and try again with error code 33 when calling friendships/destroy. According to the API docs, this call is not rate limited http://dev.twitter.com/doc/post/friendships/destroy All our API requests are authenticated with the requesting user. This happens after about 100 calls. It makes our app completely unusable. I'm guessing it's a bug, but after 3 days I'm wondering if anyone else is seeing this problem. As the errors are returned in the new error structure they didn't appear in our logs at first, so you might be experiencing this problem and not noticing. The new error structure returns a set of error messages under errors instead of just a string under error. James -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Twitter API intermittent Connection reset by peer
I'm getting some very strange intermittent errors when connecting to the API. It's completely take down our app. It looks like connections are getting reset intermittently. See a transcript below - the first attempt it works fine, then second two the connection resets. Sometimes it just hangs for minutes. james:~# wget http://twitter.com/oauth/authorize --2010-09-09 05:30:30-- http://twitter.com/oauth/authorize Resolving twitter.com... 128.242.240.148, 128.121.146.228, 128.242.245.212 Connecting to twitter.com|128.242.240.148|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2010-09-09 05:30:30 ERROR 403: Forbidden. james:~# wget http://twitter.com/oauth/authorize --2010-09-09 05:30:33-- http://twitter.com/oauth/authorize Resolving twitter.com... 168.143.171.84, 128.121.243.228, 168.143.162.52 Connecting to twitter.com|168.143.171.84|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. --2010-09-09 05:30:35-- (try: 2) http://twitter.com/oauth/authorize Connecting to twitter.com|168.143.171.84|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. Anyone else getting these problems? Doesn't happen on all the locations I test from, so I'm not sure if our IP has been blocked or go some kind of access restrictions? Our IP is 173.203.207.179 Pulling my hair out trying to figure this out since it's intermittent. James -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING
The more I think about this situation, the less I like it. At first I was happy that the service I work on was not banned by this ToS change. Even though we use twitter data for monetisation, we don't insert data into timelines. However, when I look at the services that have now been banned, I can't see any warning signs other than that they were competing with Twitter for monetising their data. This is what my service does. Even though it's not currently banned, doesn't it make sense to abandon development now? The best I can hope for it that it *isn't* wildly successful, so Twitter doesn't consider it competition... Every time I read Twitter's explanation for the situation, it reads as we know our monetisation strategy can't compete with third parties in the short term, so we're banning all competition. Hardly conducive to fostering the best solutions, particularly when Twitter will always have the upper hand with their official monetisation platform and analytics for resonance, anyway. What's even worse is the the new ToS is *still* completely ambiguous. Until I saw Peter's post here I had no idea that the ban was only in the publishing end, not insertion. Of course all this makes sense from Twitter's perspective, but for third parties... that just leaves us on an ever changing playing field with invisible goals. I could have lived with rules and rev share additions, but completely banning competition... not so much. Concerned. James PS what's the point of this paragraph from the blog post? We understand that for a few of these companies, the new Terms of Service prohibit activities in which they’ve invested time and money. We will continue to move as quickly as we can to deliver the Annotations capability to the market so that developers everywhere can create innovative new business solutions on the growing Twitter platform. a slap in the face? We understand that we've wasted your time and money, so here's the next thing for you to waste time and money on. No guarantees, no apologies. On May 26, 6:07 pm, Dean Collins d...@cognation.net wrote: Dewald, it's because you have amateurs running the zoo that are learning as they go. Honestly my opinion is that it's Twitters rights to change the rules as they go - it's their network and their right to do so, but it's also my right as an investor in application development to not invest any more time or money on Twitter until they bring in a management layer that has experience I building ecosystems and knows how to encourage sustainable development. Can you imagine if salesforce pulled a stunt like this? Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development- t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Monday, 24 May 2010 9:27 PM To: Twitter Development Talk Subject: [twitter-dev] Re: TWITTER BANS 3rd PARTY ADVERTISING Liz, You are 100% correct in summarizing the problem. Not only were those businesses built with the full knowledge of Twitter, Twitter even had specific rules governing sponsored tweets (had to be clearly marked as sponsored, etc.). I'm really baffled by this decision of Twitter, because I don't understand how they expect to have integrity and trust with developers while doing this type of stuff. Right now we are all being pointed to Annotations as the holy grail of new development. But how do we know that they won't yet again change a rule in the future that will kill businesses that were built on top of Annotations? On May 24, 3:56 pm, Liz nwjersey...@gmail.com wrote: Peter, I think the problem is that business have been created, received funding and developed over the past year, with the full knowledge of Twitter, and this just undercuts destroys them. I think people can understand the rationale (and the desire for Twitter to eliminate competition) but this is a policy decision that should have been made over a year ago. Twitter should have included this in an earlier terms of service instead of giving an implicit okay to services like Sponsored Tweets which has turned into a successful company. It also seems disingenuous that the blog post says that a guiding principle of Twitter is that We don't seek to control what users tweet. And users own their own tweets. and allow adult-oriented content and photos but for some reason, users can't Tweet ads. That sounds like control of content to me. Liz
