[twitter-dev] Re: Mobile OAuth fix is LIVE
w0t! :D
[twitter-dev] Re: A New API For Browserless Apps?
Couldn't agree more. If this is true, it's time for me to say goodbye. On Dec 10, 11:40 pm, Duane Roelands wrote: > Many of us in the developer community have been strongly pushing the > point of view that third-party apps should never be asking for user > credentials. We did so because we believed that Twitter was firmly > committed to the security of the ecosystem and protecting the accounts > of its users. It now appears that this belief was in error. > > This decision is going to actively hurt developers who chose the > more secure implementation. Application A just lets me log in with my > Twitter credentials, but Application B wants me to go through this > harder process. Most users will choose option A, and the more-secure > application B loses users. this decision punishes developers who > chose the more secure model. It's disappointing, because a lot of > developers have worked very hard to bring OAuth implementations to the > community that were robust and secure and **didn't require a user to > hand over their Twitter credentials**. > > There was a great opportunity here for Twitter to be a security leader > in the social network space by saying "We don't want our users giving > their Twitter credentials to anyone except Twitter". It's a shame > they didn't stick to their gun; the result is going to be a less- > secure ecosystem.
[twitter-dev] Source showing as web
All tweets seem to be showing as posted from web? :)
Re: Putting a ceiling on requests from users and IPs on the whitelist
Thank you, thank you! On Jan 23, 3:46 am, Alex Payne wrote: > I'm already working on this. It'll be new methods, I think. Should be > ready to deploy by early next week. > > On Thu, Jan 22, 2009 at 10:15, Scott C. Lemon wrote: > > > > > > > Alex, > > > Thank you for the quick reply ... and I agree ... it seems that > > returning the list of followers or friends as an array of IDs would be > > most effective. This is somewhat how Facebook does it with their > > API. That would allow us to gain access to the information in a much > > more compact way. > > > Obviously this would also make the amount of data being returned much > > less, as it wouldn't have to include the status of those people or > > anything else ... we can get that in subsequent requests, or by > > monitoring and caching the feed. > > > So maybe there could be two new APIs? > > >http://twitter.com/statuses/friendIDs.format > >http://twitter.com/statuses/followerIDs.format > > > What do you propose as next steps for this? Do I/we have to enter a > > bug/issue to make the request? Or are you already working on a > > solution for this? We would be very interested in seeing this new API > > so that we can fine tune our operation and minimize the number of > > requests we'll be making ... > > > Scott > > > On Jan 21, 11:49 pm, Alex Payne wrote: > >> > Can you please address the issue of how you would recommend that an > >> > application be able to fetch the total list of a users followers? I'm > >> > hearing all sorts of accusations and bluster, but want to understand > >> > from your perspective how you would propose an application do this? > > >> Right now, you can page through the lists of friends and followers. > >> We'll see about ways to get the friends list in one shot. I think our > >> best bet for a method that returns the entire set of friends or > >> followers would be simply returning an array of user IDs. > > >> > Even here on the list there are people suggesting that you enhance the > >> > API to simply drop the current status ... and only return the list of > >> > followers ... which would seem to be a much simpler, and less > >> > intensive, query. > > >> We'll certainly consider that. > > >> > As a side note, we are currently working on three twitter > >> > applications ... two that are hosted services, and one that is a > >> > desktop application. I want to ensure that we continue to build these > >> > fully understanding how to work cooperatively with you! > > >> All you need to do is send us an email, and we'll find solutions. It > >> may take some time if the solution you need isn't on our development > >> roadmap, but we're here to make it happen. > > >> -- > >> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > -- > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: alpha test of a new service: Tweetpass
But won't OAuth put an end to this requirement anyway? --Swap On Jan 8, 6:04 am, Brian Hendrickson wrote: > On Jan 7, 1:00 pm, "Chad Etzel" wrote: > > > By logging intohttp://tweetpass.com/api/doyou automatically store > > the password somewhere? If so, how is it stored? encrypted? > > Yes, each user's twitter password is encrypted and stored in the SQL > database. It's not on dreamhost, though :-) the server is physically > controlled, in a high-end co-location facility in Portland. > > When an API call comes in with a disposable password, the twitter > password is fetched from the database and used to make the call to the > twitter.com API > > Also, the first time a disposable password is used, it is labeled with > the incoming hostname and will only be good for that host. API events > for that password are visible in the control panel. > > -- Brian
Re: Getting 503 errors with search API
I recommend getting your IP white listed. http://twitter.com/help/request_whitelisting On Jan 4, 9:16 am, Amir Michail wrote: > Hi, > > What would be reasonable usage for the search API? > > And if I need more, can I request more? > > I'm making the requests server-side without authentication. > > Amir
Re: user_timeline Only Returns 4 Pages?
I too have noticed this issue with an account with "0" or "1" following. On Dec 19, 6:24 am, Fahim wrote: > Hi, > > I have an app which keeps track of the last fetched tweet ID and then > pulls all tweets since then. In the mornings, when I've had my app > offline all night, it usually has to g back and pull multiple pages of > tweets by using the page and count parameters in conjunction with the > since_id parameter. > > The last few days it appears that it doesn't fetch anything beyond > page 4. For instance, if I use the following URL to fetch all tweets > since last night, I only get up to 4 pages and then page 5 onwards has > no > data:http://twitter.com/statuses/friends_timeline.xml?since_id=1065043064&;... > > Is this normal behaviour? I didn't think it worked like this before > and that it returned however many pages (back to 24 hours) of data > there was. Am I imagining things or has something changed? > > Regards, > > Fahim
Re: verify_credentials response changed
yes, follow the api bot @twitterapi On Dec 11, 9:32 pm, JakeS wrote: > Really, I don't get emails from this group because it's often full of > people's questions that do not relate to me. > > Is there a better way we can be notified of API changes without all > the extra conversation from the group? > > On Dec 11, 10:30 am, Stut wrote: > > > On 11 Dec 2008, at 16:20, JakeS wrote: > > > > It used to be that > > > callinghttp://twitter.com/account/verify_credentials.xml > > > would return a simple "true" answer when > > > given a correct username and password. Now it appears to be > > > returning an entire serialized user object. > > > > This change has broken the authentication process for the existing > > > releases of my application. Is this change permanent, or is it a > > > temporary glitch? > > > Plenty of notice was given for this change... > > >http://groups.google.com/group/twitter-development-talk/browse_thread... > > > -Stut > > > --http://stut.net/
Re: Testing URL
Something close to a sandbox? Sounds cool. On Dec 11, 10:17 am, Hamish Campbell wrote: > Hi all, > > Perhaps this already exists, but if not it would be great: a URL or > flag for API testing. > > Eg, all requests to this service would process the queries for only > for validity of the message (and ignore whether the status/user/ > favorite etc exists) and return an sample dataset as would be expected > of a successful request. > > Malformed requests would return the expected failure notice, and > perhaps a 'return false' flag could be added to tell the api to send > the relevant negative response for a particular request. > > Since it would have no effect on any actual data, it would not need to > be rate limited (or at least the rate could be extremely high and only > by I.P.). > > This would be great for unit testing. At the moment it's difficult to > create a testing framework that works reliably. Especially if you want > other people to be able to run the tests, but not see your twitter > password :P. For example, you have to generate a random status message > to avoid the 'ignore repeated messages' issue, and create and destroy > friendships and notifications that you've manually set up. > > It's not a biggie, but would be a very useful developer tool. > > Thanks!
Re: INCOMPATIBILITY ALERT: response body of /account/verify_credentials changing Dec 10th
It does return an error (along with the header) as well. Thanks for adding the user data to this call. Saves an extra call for our service. -- Swap On Dec 11, 7:07 am, "Alex Payne" <[EMAIL PROTECTED]> wrote: > Just a reminder: today was the day for this change to go live, and it > just went live. > > > > On Thu, Dec 4, 2008 at 12:42, Brooks Bennett <[EMAIL PROTECTED]> wrote: > > > I agree, this is a great change. > > > On Dec 3, 11:07 pm, "dean.j.robinson" <[EMAIL PROTECTED]> > > wrote: > >> "return the representation of the authenticated user" > > >> does that mean that the response will be the same as if we > >> calledhttp://twitter.com/users/show/id.format for the authenticated user? > >> If so that would be awesome and means I could completely eliminate > >> some of the extra api calls that I'm making. Doesn't matter too much > >> either way though, since both Hahlo 3.1 and Hahlo 4 (which I've > >> recently begun work on) both currently use the http status for > >> confirmation. > > >> thanks for the heads up. > > >> On Dec 3, 1:14 pm, "Alex Payne" <[EMAIL PROTECTED]> wrote: > > >> > As perhttp://code.google.com/p/twitter-api/issues/detail?id=173we'll > >> > be changing the /account/verify_credentials method to return the > >> > representation of the authenticated user. Because some applications > >> > depend on the contents of this response, we're delaying this change > >> > until December 10th, 2008. > > >> > Please update your applications to verify by response code, not by the > >> > response body for this method. If you get a 200 back, you're > >> > verified. If you get a 401 back, you're not. > > >> > If you can't ship an update in 8 days, please let us know and we'll > >> > push the date out further. > > >> > -- > >> > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > -- > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: since_id limit
No, just use the count (200) parameter if you want all tweets since "that" id. -- Swap On Dec 4, 12:40 am, Trevor Turk <[EMAIL PROTECTED]> wrote: > On Dec 3, 11:39 am, Swap <[EMAIL PROTECTED]> wrote: > > > There was a small change. They fixed a bug with since_id where it > > would set it as 0 if the status had been deleted (#77). It looks like > > they now require a count parameter as well. > > So what's a good workaround? Request the next page if you get 20 > results? Too bad, but still doable :) > > - Trevor
Re: since_id limit
There was a small change. They fixed a bug with since_id where it would set it as 0 if the status had been deleted (#77). It looks like they now require a count parameter as well. -- Swap On Dec 3, 1:12 pm, Fahim <[EMAIL PROTECTED]> wrote: > But didn't the since_id parameter return all tweets since that ID > originally? I have a Twitter client that I've coded which was working > fine with since_id till yesterday (December 1st). But since yesterday > it only returns the last 20 tweets. Was a functionality/API change > made? > > On Dec 1, 6:38 pm, "Brian Gilham" <[EMAIL PROTECTED]> wrote: > > > If there are more than 20 results, you can use paging to grab them all. > > Kind regards, > > Fahim
Re: Rate limit exceeded for whitelisted app
Thanks Alex! On Dec 3, 8:15 am, "Alex Payne" <[EMAIL PROTECTED]> wrote: > The updated estimate I've just received from our ops guys is "more > than 15 minutes and less than 12 hours". They have to restore from a > nightly database backup. Said backups are quite large, and take some > time to get through. Thanks for your patience. > > > > On Tue, Dec 2, 2008 at 18:39, Yu-Shan Fung <[EMAIL PROTECTED]> wrote: > > Thanks for being so responsive. You guys rock! > > > On Tue, Dec 2, 2008 at 6:37 PM, Alex Payne <[EMAIL PROTECTED]> wrote: > > >> Just talked to our Operations team. It looks like some database > >> maintenance inadvertently truncated our table of whitelisted users. > >> We're restoring that as I type and everything will be back to normal > >> shortly. > > >> On Tue, Dec 2, 2008 at 18:25, Alex Payne <[EMAIL PROTECTED]> wrote: > >> > No, there's no change in policy, but perhaps we have a bug. Yours is > >> > the second report of a rate limit issue. > > >> > On Tue, Dec 2, 2008 at 18:23, Yu-Shan Fung <[EMAIL PROTECTED]> > >> > wrote: > >> >> Hi, > >> >> Our app (mrtweet.net), which has been whitelisted (@mrtweet) since a > >> >> couple > >> >> of weeks back, has suddenly began seeing the "rate limit exceeded" > >> >> error > >> >> since around 3:45pm (pacific) today. Was there a change in policy, or > >> >> do I > >> >> have to reapply for whitelisting? > >> >> Thanks! > >> >> Yu-Shan. > > >> > -- > >> > Alex Payne - API Lead, Twitter, Inc. > >> >http://twitter.com/al3x > > >> -- > >> Alex Payne - API Lead, Twitter, Inc. > >>http://twitter.com/al3x > > > -- > > "Reality is that which, when you stop believing in it, doesn't go away." > > - Philip K. Dick, American Writer > > -- > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
