[twitter-dev] reply_to_status_id == 0
I'm working on Favorites and a user of ours has status id #773146783 which for some reason is showing reply_to_status_id of 0. This is mucking with my parsing code and I'd rather not add a special-case. Any one else seeing similar issues, have suggestions?
[twitter-dev] Looking for Twitter API Developer
I am looking for an experienced Twitter API Developer for a project. Without disclosing the details, it would require the following: - List of latest X number of tweets from a list of twitter users (IE I will specify dozens, or even hundreds of twitter users who I want to follow, on my site it should display the 20 (for example) latest posts from the specified users) - Show a list of the 10 users with the most followers (from a list of several hundred users which I will supply) On the main page I'd like the above, then have a subset of the list with the same features on subsequent pages. This site has a great example of exactly the kind of feed I am looking for: http://www.celebritytweet.com/ I also need to be able to add/remove usernames from the list at any time, this list will be constantly added to. If you are interested in this project, please reply to this thread with your contact info and some examples for twitter API apps you've already built. Also, a quote and time frame for completion would be helpful. I will get in touch with you. Thanks, I look forward to hearing from you! Jon
[twitter-dev] Re: Can we make this a private list?
On Tue, Mar 31, 2009 at 5:48 PM, Andrew Badera and...@badera.us wrote: And there's no reason in the world to expose this list to people who aren't making API calls -- period! This line suggests that you should be currently developing an app (thus making API calls) to access this list, which is contrary to what almost everyone has already said in this thread. I think this thread has out lived it's usefulness. Most everyone seems to agree it is in everyones best interest to keep this group open to all. If you have something you need to keep private please consider some other means than this group _cts
[twitter-dev] Re: Delay in display of profile image updated via API
The lag wasn't nearly as noticeable when the update_profile_image was first offered, but has since as you noted become considerable. As a work around my app, which updates profile images from a local source, uses the local source to represent the new avatar after I receive the HTTP status codes that indicate the upload was successful. Ideally I'd like to grab the new image from twitter and use that, as a bit of extra confirmation, but that doesn't seem to be feasible at this time _cts On Wed, Apr 1, 2009 at 7:37 AM, Cameron Kaiser spec...@floodgap.com wrote: I am able to update my profile image using curl. But the new image doesn't come up immediately near my tweets. Instead I find my full name at that place. It shows up only after an hour or so. BTW, if I access http://twitter.com/account/profile_image/X (X being the username), I can see the newly updated image immediately. This problem is not noticed if I update my profile image using a web browser. What is the way to update profile image via API so that the newly updated image come up near your tweets immediately? If I'm understanding you correctly, there isn't. There is a lag while the new image gets propagated to the servers. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Two can live as cheaply as one, for half as long. --
[twitter-dev] Re: Search queries not working
Hi Basha, The max_id is only intended to be used for pagination via the next_url and prev_url fields and is known not to work with since_id. It is not documented as a valid parameter because it's known to only work in the case it was designed for. We added the max_id to prevent the problem where you click on 'Next' and page two starts with duplicates. Here's the scenario: 1. Let's say you search for 'foo'. 2. You wait 10 seconds, during which 5 people send tweets containing 'foo'. 3. You click next and go to page=2 (or call page=2 via the API) 3.a. If we displayed results 21-40 the first 5 results would look like duplicates because they were pushed down by the 5 new entries. 3.b. If we append a max_id from the time you searched we can do and offset from the maximum and the new 5 entries are skipped. We use option 3.b. (as does twitter.com now) so you don't see duplicates. Since we wanted to provide the same data in the API as the UI we added the next_url and prev_url members in our output. Thanks; — Matt Sanford On Mar 31, 2009, at 08:42 PM, Basha Shaik wrote: HI Matt, when Since_id and Max_id are given together, max_id is not working. This query is ignoring max_id. But with only since _id its working fine. Is there any problem when max_id and since_id are used together. Also please tell me what does max_id exactly mean and also what does it return when we send a request. Also tell me what the total returns. Regards, Mahaboob Basha Shaik www.netelixir.com Making Search Work On Tue, Mar 31, 2009 at 3:22 PM, Matt Sanford m...@twitter.com wrote: Hi there, Can you provide an example URL where since_id isn't working so I can try and reproduce the issue? As for language, the language identifier is not a 100% and sometimes makes mistakes. Hopefully not too many mistakes but it definitely does. Thanks; — Matt Sanford / @mzsanford On Mar 31, 2009, at 08:14 AM, codepuke wrote: Hi all; I see a few people complaining about the since_id not working. I too have the same issue - I am currently storing the last executed id and having to check new tweets to make sure their id is greater than my last processed id as a temporary workaround. I have also noticed that the filter by language param also doesn't seem to be working 100% - I notice a few chinese tweets, as well as tweets having a null value for language...
[twitter-dev] Re: reply_to_status_id == 0
That value looks like bogus data. That tweet is from @biz, a Twitter co-founder. You can do anything you want when you are co-founder -- like setting in_reply_to_status_id's equal to 0. Doug Williams Twitter API Support http://twitter.com/dougw On Tue, Mar 31, 2009 at 9:15 PM, Joshua Perry j...@6bit.com wrote: I'm working on Favorites and a user of ours has status id #773146783 which for some reason is showing reply_to_status_id of 0. This is mucking with my parsing code and I'd rather not add a special-case. Any one else seeing similar issues, have suggestions?
[twitter-dev] Re: reply_to_status_id == 0
Seriously! Take his MySQL access away. Doug Williams wrote: That value looks like bogus data. That tweet is from @biz, a Twitter co-founder. You can do anything you want when you are co-founder -- like setting in_reply_to_status_id's equal to 0. Doug Williams Twitter API Support http://twitter.com/dougw On Tue, Mar 31, 2009 at 9:15 PM, Joshua Perry j...@6bit.com mailto:j...@6bit.com wrote: I'm working on Favorites and a user of ours has status id #773146783 which for some reason is showing reply_to_status_id of 0. This is mucking with my parsing code and I'd rather not add a special-case. Any one else seeing similar issues, have suggestions?
[twitter-dev] Re: reply_to_status_id == 0
couldn't this actually happen a lot though, if you wrote an app and were passing in this value and the value got dropped? or does the system ignore this? On Wed, Apr 1, 2009 at 10:39 AM, Joshua Perry j...@6bit.com wrote: Seriously! Take his MySQL access away. Doug Williams wrote: That value looks like bogus data. That tweet is from @biz, a Twitter co-founder. You can do anything you want when you are co-founder -- like setting in_reply_to_status_id's equal to 0. Doug Williams Twitter API Support http://twitter.com/dougw On Tue, Mar 31, 2009 at 9:15 PM, Joshua Perry j...@6bit.com wrote: I'm working on Favorites and a user of ours has status id #773146783 which for some reason is showing reply_to_status_id of 0. This is mucking with my parsing code and I'd rather not add a special-case. Any one else seeing similar issues, have suggestions? -- Peter M. Denton www.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter - http://tinyurl.com/bopu6c
[twitter-dev] Re: reply_to_status_id == 0
Peter, As was described here [1], invalid in_reply_to_status_id's are no longer accepted. We now verify the status_id is valid and that the author is being mentioned. Otherwise the parameter is ignored. 1. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3ce9d702f61d8a2c?hl=en Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 1, 2009 at 10:42 AM, Peter Denton petermden...@gmail.comwrote: couldn't this actually happen a lot though, if you wrote an app and were passing in this value and the value got dropped? or does the system ignore this? On Wed, Apr 1, 2009 at 10:39 AM, Joshua Perry j...@6bit.com wrote: Seriously! Take his MySQL access away. Doug Williams wrote: That value looks like bogus data. That tweet is from @biz, a Twitter co-founder. You can do anything you want when you are co-founder -- like setting in_reply_to_status_id's equal to 0. Doug Williams Twitter API Support http://twitter.com/dougw On Tue, Mar 31, 2009 at 9:15 PM, Joshua Perry j...@6bit.com wrote: I'm working on Favorites and a user of ours has status id #773146783 which for some reason is showing reply_to_status_id of 0. This is mucking with my parsing code and I'd rather not add a special-case. Any one else seeing similar issues, have suggestions? -- Peter M. Denton www.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter - http://tinyurl.com/bopu6c
[twitter-dev] Re: reply_to_status_id == 0
Solution: Create a status with id = 0. On Wed, Apr 1, 2009 at 12:51, Doug Williams d...@twitter.com wrote: Peter, As was described here [1], invalid in_reply_to_status_id's are no longer accepted. We now verify the status_id is valid and that the author is being mentioned. Otherwise the parameter is ignored. 1. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/3ce9d702f61d8a2c?hl=en Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 1, 2009 at 10:42 AM, Peter Denton petermden...@gmail.comwrote: couldn't this actually happen a lot though, if you wrote an app and were passing in this value and the value got dropped? or does the system ignore this? On Wed, Apr 1, 2009 at 10:39 AM, Joshua Perry j...@6bit.com wrote: Seriously! Take his MySQL access away. Doug Williams wrote: That value looks like bogus data. That tweet is from @biz, a Twitter co-founder. You can do anything you want when you are co-founder -- like setting in_reply_to_status_id's equal to 0. Doug Williams Twitter API Support http://twitter.com/dougw On Tue, Mar 31, 2009 at 9:15 PM, Joshua Perry j...@6bit.com wrote: I'm working on Favorites and a user of ours has status id #773146783 which for some reason is showing reply_to_status_id of 0. This is mucking with my parsing code and I'd rather not add a special-case. Any one else seeing similar issues, have suggestions? -- Peter M. Denton www.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter - http://tinyurl.com/bopu6c -- Abraham Williams | Hacker | http://abrah.am @poseurtech | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] lots of requests
I am developing a Twitter based app running on Google's App Engine - http://twittemmender.appspot.com (it is up but not working properly right now) The main idea is to recommend you tweeps that are close to you based on your latest tweets (and some machine learning on your tweets). For this I need to get a list of all my friends (easy and fast enough to do right now), and then for each of those friends get a list of all their friends (this is where it starts getting slow because this could add up to about 10,000 friends). Then for each of those second degree friends I would like to retrieve their latest tweets (20 tweets for example). This means I would have to make ~ 10,000 requests. I am currently using the python twitter library, which works fine for a few requests (ex: just getting my latest tweets, or getting a list of my friends), but as soon as I request the friends of friends (second degree friends), things start getting slow. My question is, is there a good way of doing this? Maybe some batch requests or something similar? Thank you, Twitter API folks! Your help is appreciated!
[twitter-dev] Re: Twitter user picture sizes
Thanks Alex for making sure this gets taken care of. It's been driving me nuts here chasing ghosts why my IO appears to be blocked when its actually trying to just pull a massive image. Basically I'm having all the same issue other are having... My IO library doesn't make it easy to cancel a transfer that is partially complete for our client (doable but increases the complexity a lot), one big image can invalidate several older images in my cache engine because of memory constraints and I don't want to write resizing code before I put it in the cache, and it creates a bottleneck because our client runs where bandwidth is usually small quiet often, etc, etc. You know the deal :-) Zac Bowling On Mon, Mar 30, 2009 at 12:23 PM, Alex Payne a...@twitter.com wrote: It's one of our top issues right now. On Sun, Mar 29, 2009 at 23:05, Andrew Maizels andrew.maiz...@gmail.com wrote: We'd really like to see a fix for this too. Having a few hundred unexpectedly large images floating around is playing havoc with our memory usage. Regards, Andrew Maizels PeopleBrowsr On Mar 26, 2:53 pm, Jason Schroeder jasch...@gmail.com wrote: Here is a 480x480 _normal image:http://s3.amazonaws.com/twitter_production/profile_images/108666778/I... Any progress on working with the UX team to resize these? TwitterBerry is expecting a 48x48-pixel image. Cheers, Jason TwitterBerry On Mar 24, 7:49 am, Shannon Whitley shannon.whit...@gmail.com wrote: Don't forget the _mini. :) This is my list: (original) _mini _normal _bigger On Feb 25, 12:15 am, Dave Briccetti da...@davebsoft.com wrote: Hi. I’ve searched around for 1/2 hour or so, and haven’t found an authoritative explanation of the sizes of pictures, and how to retrieve them. It seems that profile_image_url leads to a tiny picture: http://s3.amazonaws.com/twitter_production/profile_images/66123958/IM... But there is also a slighter bigger version: http://s3.amazonaws.com/twitter_production/profile_images/66123958/IM... And then a proper full-sizeone: http://s3.amazonaws.com/twitter_production/profile_images/66123958/IM... Am I correct in this? That the big version URL can be derived from that in profile_image_url by dropping the _normal from the name? Is this part of the API spec? Safe to use? Thanks. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Random 'From' values
I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine).
[twitter-dev] Re: Random 'From' values
OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker | http://abrah.am @poseurtech | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report:http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] search fine time interval
Hi All, Is it possible to search a finer time interval that a day? For example search between 12:00 and 1:00 on a specific day. I have tried numerous formats to extend the since and until operators to include hour:minute:second with no luck. Many thanks, Cestino
[twitter-dev] Re: Random 'From' values
And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report:http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
It definitely sounds like a bug. Open an issue and we'll take a look. Thanks; — Matt Sanford On Apr 1, 2009, at 02:21 PM, AhmedF wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report:http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
Try using source=twhirl and see if it shows up as Twhirl and sticks. On Wed, Apr 1, 2009 at 16:21, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States -- Abraham Williams | Hacker | http://abrah.am @poseurtech | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
Ahmed, Are you currently passing in anything with your requests as a source parameter? Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 1, 2009 at 2:21 PM, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: search fine time interval
Cestino, Search only allows dates to be specified down to the day. We don't allow the granularity to be more specific than that. If you are only looking for a specific hour, our current recommendation is to do client-side filtering. Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 1, 2009 at 1:58 PM, Cestino paulstantonea...@gmail.com wrote: Hi All, Is it possible to search a finer time interval that a day? For example search between 12:00 and 1:00 on a specific day. I have tried numerous formats to extend the since and until operators to include hour:minute:second with no luck. Many thanks, Cestino
[twitter-dev] Re: Random 'From' values
Newp - ignored it. I tried it with source='Twhirl' and source='twhirl' I even just passed only a status value (that part has always worked). Bouncing between random 'from' sources for all of my OAuth posts. I'll admit I'm new to OAuth, and I am using Abraham's PHP example code, but I've been coding for long enough to think my request is fine. On Apr 1, 5:23 pm, Abraham Williams 4bra...@gmail.com wrote: Try using source=twhirl and see if it shows up as Twhirl and sticks. On Wed, Apr 1, 2009 at 16:21, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
Matt will look into your report [1]. Thanks for the report, Ahmed. 1. http://code.google.com/p/twitter-api/issues/detail?id=408 Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 1, 2009 at 2:29 PM, AhmedF inde...@gmail.com wrote: I've left it empty and tried 'source' or even 'from' - always comes up with something random. On Apr 1, 5:23 pm, Doug Williams d...@twitter.com wrote: Ahmed, Are you currently passing in anything with your requests as a source parameter? Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 1, 2009 at 2:21 PM, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
In my experience. If you are posting from an OAuth enabled app, the From value (should) be the value you put into the OAuth app name form when creating the app. All source parameters passed will be ignored. I would imagine this is a pretty good security measure to help track down malapps (yes, you heard it hear first, folks... malapps will be the biggest new InfoSec term this century!). If you are posting from a Basic Auth app, it will use the source parameter. That being said, however, this behavior sounds like a bug. -Chad On Wed, Apr 1, 2009 at 5:29 PM, AhmedF inde...@gmail.com wrote: I've left it empty and tried 'source' or even 'from' - always comes up with something random. On Apr 1, 5:23 pm, Doug Williams d...@twitter.com wrote: Ahmed, Are you currently passing in anything with your requests as a source parameter? Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 1, 2009 at 2:21 PM, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Can we make this a private list?
Perhaps it may be possible to have some kind of community agreement on a don't Tweet meta-character. Obviously this would be usless for bots that didn't follow the request but would be a start. On Mar 29, 11:23 pm, Chad Etzel jazzyc...@gmail.com wrote: Hi All, Wondering what everyone's feelings would be toward making this a private list. It is becoming more apparent that the feed for this list is being used to blast out posts to the void almost immediately after posting and makes it hard to ask private/closed group questions or get feedback about an unlaunched app before you go public with it. Case in point: I just posted about my iPhone webapp a little while ago asking for dev feedback before announcing it publicly, and already there are 3 tweets linking to the post:http://twitter.com/twittes1/status/1414300783http://twitter.com/twittea/status/1414269472http://twitter.com/ianonmac/status/1414254749 There was also at least one blog that would just copy the content of every post from the RSS feed and jam a ton of ads around it hoping to get clicks off of people just searching for twitter related stuff. I've never admin'd a Google Group before, but is there a way to make this list a little more closed? Or at least turn off the RSS feed? Thoughts? -Chad
[twitter-dev] Getting a 401 when trying to get OAuth access token
I am working on writing and OAuth client in Java for Twitter and I am
hitting the wall when trying to get the Access Token. I am able to
successfully get a sign and get a token, forward to the authorize
page, get a response, but after that, when trying to get the Access
Token, it dies. The following is my flow:
I am first sending a message with the following information to get the
token:
OAuthMessage(GET, http://twitter.com/oauth/request_token,
[oauth_consumer_key=RmhOF3YvERsY1uVF68tKg, oauth_signature_method=HMAC-
SHA1, oauth_timestamp=1238616948, oauth_nonce=1238616948972478000,
oauth_version=1.0, oauth_signature=itlw1V%2FSbJzHyU8VHs0wu4uMWew%3D])
This is the URL:
http://twitter.com/oauth/request_token?oauth_consumer_key=RmhOF3YvERsY1uVF68tKgoauth_signature_method=HMAC-SHA1oauth_timestamp=1238616948oauth_nonce=1238616948972478000oauth_version=1.0oauth_signature=itlw1V%2FSbJzHyU8VHs0w
That seems to work great and I get back a response and a token:
[Date=Wed%2C%2001%20Apr%202009%2020%3A17%3A51%20GMT, Server=hi, Last-
Modified=Wed%2C%2001%20Apr%202009%2020%3A17%3A51%20GMT,
Status=200%20OK, ETag=%227b36526f344e3ae8dc0efa12532c71a9%22,
Pragma=no-cache, Cache-Control=no-cache%2C%20no-store%2C%20must-
revalidate%2C%20pre-check%3D0%2C%20post-check%3D0, Content-Type=text
%2Fhtml%3B%20charset%3DUTF-8, Content-Length=112, Expires=Tue%2C
%2031%20Mar%201981%2005%3A00%3A00%20GMT, X-
Revision=cac1726f8303dbd4844ed052d9f60f2118d51b8f, X-
Transaction=1238617071-29428-3892, Set-Cookie=_twitter_sess
%3DBAh7BzoHaWQiJTdjZDc4NDI5YzRmOTRmMDM5ODY2ODA4Njc0MmI1NjFlIgpm
%25250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%25250AOgpAdXNlZHsA--14ba7530dbc9101ea124fcf397ec1d3acd924c0b%3B
%20domain%3D.twitter.com%3B%20path%3D%2F, Vary=Accept-Encoding,
Connection=close]
Response Parameters:
{oauth_token=eKznWjog00qLi5VIWXKwWql89RyIRPuzKJHVKj0,
oauth_token_secret=secret is populated here}
Then, I use that Token to create the link to the Authorization page:
Twitter Authentication
http://twitter.com/oauth/authorize?oauth_token=eKznWjog00qLi5VIWXKwWql89RyIRPuzKJHVKj0oauth_callback=http%3A%2F%2Flocalhost%3A8080%2Fdc%2Ftwitterauth
After that comes back, I try to get the Access Token with the
following:
http://twitter.com/oauth/access_token?oauth_consumer_key=RmhOF3YvERsY1uVF68tKgoauth_signature_method=HMAC-SHA1oauth_timestamp=1238617482oauth_nonce=1238617482950207000oauth_version=1.0oauth_signature=b%2FInX%2BiBuMlREF99oFUeZYymuAg%3D
This is where I am hitting the wall, because it is coming back as
unauthorized:
Access Token Response Headers:
[Date=Wed%2C%2001%20Apr%202009%2020%3A25%3A57%20GMT, Server=hi, Last-
Modified=Wed%2C%2001%20Apr%202009%2020%3A25%3A57%20GMT,
Status=401%20Unauthorized, Pragma=no-cache, Cache-Control=no-cache%2C
%20no-store%2C%20must-revalidate%2C%20pre-check%3D0%2C%20post-check
%3D0, Content-Type=text%2Fhtml%3B%20charset%3DUTF-8, Content-Length=1,
Expires=Tue%2C%2031%20Mar%201981%2005%3A00%3A00%20GMT, X-
Revision=cac1726f8303dbd4844ed052d9f60f2118d51b8f, X-
Transaction=1238617557-17087-17303, Set-Cookie=_twitter_sess
%3DBAh7BzoHaWQiJTZmMTA0N2RlNzUwZjhmY2ViY2U0Yzk5MjBhNDcwYjY4Igpm
%25250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%25250AOgpAdXNlZHsA--036987088c0603e72c0639000d32ea9cf1265fbe%3B
%20domain%3D.twitter.com%3B%20path%3D%2F, Vary=Accept-Encoding,
Connection=close]
{HTTP request=GET /oauth/access_token?
oauth_consumer_key=RmhOF3YvERsY1uVF68tKgoauth_signature_method=HMAC-
SHA1oauth_timestamp=1238617482oauth_nonce=1238617482950207000oauth_version=1.0oauth_signature=b
%2FInX%2BiBuMlREF99oFUeZYymuAg%3D
User-Agent: Jakarta Commons-HttpClient/3.1
Host: twitter.com
, HTTP status=401, HTTP response=HTTP/1.1 401 Unauthorized
Date: Wed, 01 Apr 2009 20:25:57 GMT
Server: hi
Last-Modified: Wed, 01 Apr 2009 20:25:57 GMT
Status: 401 Unauthorized
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-
check=0
Content-Type: text/html; charset=UTF-8
Content-Length: 1
Expires: Tue, 31 Mar 1981 05:00:00 GMT
X-Revision: cac1726f8303dbd4844ed052d9f60f2118d51b8f
X-Transaction: 1238617557-17087-17303
Set-Cookie:
_twitter_sess=BAh7BzoHaWQiJTZmMTA0N2RlNzUwZjhmY2ViY2U0Yzk5MjBhNDcwYjY4Igpm
%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%250AOgpAdXNlZHsA--036987088c0603e72c0639000d32ea9cf1265fbe;
domain=.twitter.com; path=/
Vary: Accept-Encoding
Connection: close
, URL=http://twitter.com/oauth/access_token?
oauth_consumer_key=RmhOF3YvERsY1uVF68tKgoauth_signature_method=HMAC-
SHA1oauth_timestamp=1238617482oauth_nonce=1238617482950207000oauth_version=1.0oauth_signature=b
%2FInX%2BiBuMlREF99oFUeZYymuAg%3D}
I am not sure if you can tell much from that, but any pointers are
welcome and appreciated.
[twitter-dev] Re: Random 'From' values
I guess just for future reference - Matt looked into it, identified it as a bug, and said it should be fixed soon. Thanks. On Apr 1, 5:40 pm, Chad Etzel jazzyc...@gmail.com wrote: In my experience. If you are posting from an OAuth enabled app, the From value (should) be the value you put into the OAuth app name form when creating the app. All source parameters passed will be ignored. I would imagine this is a pretty good security measure to help track down malapps (yes, you heard it hear first, folks... malapps will be the biggest new InfoSec term this century!). If you are posting from a Basic Auth app, it will use the source parameter. That being said, however, this behavior sounds like a bug. -Chad On Wed, Apr 1, 2009 at 5:29 PM, AhmedF inde...@gmail.com wrote: I've left it empty and tried 'source' or even 'from' - always comes up with something random. On Apr 1, 5:23 pm, Doug Williams d...@twitter.com wrote: Ahmed, Are you currently passing in anything with your requests as a source parameter? Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 1, 2009 at 2:21 PM, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Random 'From' values
Ahmed, This is a confirmed bug. The good news is Matt and Alex tag-teamed it and have the fix readied for deploy. Cheers, Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 1, 2009 at 3:23 PM, AhmedF inde...@gmail.com wrote: I guess just for future reference - Matt looked into it, identified it as a bug, and said it should be fixed soon. Thanks. On Apr 1, 5:40 pm, Chad Etzel jazzyc...@gmail.com wrote: In my experience. If you are posting from an OAuth enabled app, the From value (should) be the value you put into the OAuth app name form when creating the app. All source parameters passed will be ignored. I would imagine this is a pretty good security measure to help track down malapps (yes, you heard it hear first, folks... malapps will be the biggest new InfoSec term this century!). If you are posting from a Basic Auth app, it will use the source parameter. That being said, however, this behavior sounds like a bug. -Chad On Wed, Apr 1, 2009 at 5:29 PM, AhmedF inde...@gmail.com wrote: I've left it empty and tried 'source' or even 'from' - always comes up with something random. On Apr 1, 5:23 pm, Doug Williams d...@twitter.com wrote: Ahmed, Are you currently passing in anything with your requests as a source parameter? Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 1, 2009 at 2:21 PM, AhmedF inde...@gmail.com wrote: And a little follow up - so I updated that status 30 minutes ago, where it claimed the from was 'TVTweets'. Just tried again, and now both of the messages are from 'Testery' I guess something is definitely buggy. On Apr 1, 5:17 pm, AhmedF inde...@gmail.com wrote: As it is - I am using your code as the base for the OAuth transaction - and all attempts to set source/from have failed. I'm waiting on getting approved as a legit 'from' field and then seeing what happens. On Apr 1, 5:10 pm, Abraham Williams 4bra...@gmail.com wrote: OAuth apps automatically get their source info added. The app ids must be getting jumbled somewhere. A work around might be to manually set source=web or whatever source you want. Try creating an bug report: http://code.google.com/p/twitter-api/issues/list On Wed, Apr 1, 2009 at 15:46, AhmedF inde...@gmail.com wrote: I'm testing out a pretty simple OAuth app - the user verifies, and I then push an update to their status. The confounding part is I am getting absolutely random values in the 'From' field. It was originally Coolspotters, now TVtweets, and I can only be curious as to what it chooses next. The API says I can only set 'status' and optionally 'in_reply_to_status_id' - anyone know why I am getting these random values? (the status message itself is posting just fine). -- Abraham Williams | Hacker |http://abrah.am @poseurtech |http://the.hackerconundrum.com Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Can we make this a private list?
On 4/1/09 5:51 PM, rhysmeister wrote: Perhaps it may be possible to have some kind of community agreement on a don't Tweet meta-character. Obviously this would be usless for bots that didn't follow the request but would be a start. Maybe it wasn't a popular meme, but does anyone remember this one: Do you know how to keep a secret? Good, so do I. :-) -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] API Changes for April 1, 2009
(Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: [twitter-api-announce] API Changes for April 1, 2009
Does this include the Social Graph API methods? Jesse On Wed, Apr 1, 2009 at 6:34 PM, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
Fantastic news. Are the direct message's recipient and sender objects updated as well? Zac Bowling http://twitter.com/zbowling On Wed, Apr 1, 2009 at 5:34 PM, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: [twitter-api-announce] API Changes for April 1, 2009
No, only methods that previously returned User objects. On Wed, Apr 1, 2009 at 17:54, Jesse Stay jesses...@gmail.com wrote: Does this include the Social Graph API methods? Jesse On Wed, Apr 1, 2009 at 6:34 PM, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
Egads! No, they aren't, but that's a quick fix. Will have it out tomorrow, hopefully, Monday at the latest. On Wed, Apr 1, 2009 at 17:57, Zac Bowling zbowl...@gmail.com wrote: Fantastic news. Are the direct message's recipient and sender objects updated as well? Zac Bowling http://twitter.com/zbowling On Wed, Apr 1, 2009 at 5:34 PM, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes at http://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats! http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Invalid OAuth Request when checking Friendship Exists (with GET)
Hi guy, I have just integrated OAuth into my web app, and all is going well except for one thing: When I call friendships/exists I always receive Invalid OAuth Request. It seems that if my request to friendships/exists works if it is a POST, but if it is a GET it never works. Can I rely that the POST will always work? Thanks, Chris.
[twitter-dev] Re: API Changes for April 1, 2009
Sorry, I meant statuses_count. On Apr 1, 7:23 pm, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats!http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] How to add an open source project into wiki?
http://apiwiki.twitter.com/Libraries and http://apiwiki.twitter.com/Open-source Thanks -- Gary http://twitter.com/garyzhao
[twitter-dev] Re: API Changes for April 1, 2009
On Wed, Apr 1, 2009 at 9:33 PM, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. Sorry, I meant statuses_count. nor favourites_count, nor friends_count... here's my record, in full (from /users/show/damon.xml) $ curl http://twitter.com/users/show/damon.xml ?xml version=1.0 encoding=UTF-8? user id756264/id nameDamon Clinkscales/name screen_namedamon/screen_name locationAustin, TX/location descriptionI'm a shepherd. Software engineer at VitalSource and leader of Austin On Rails. I also build apps like http://snaptweet.com and http://doesfollow.com. /description profile_image_urlhttps://s3.amazonaws.com/twitter_production/profile_images/73617066/me_smile_normal.jpg/profile_image_url urlhttp://damonc.com/url protectedfalse/protected followers_count974/followers_count status created_atWed Apr 01 21:16:29 + 2009/created_at id1434142066/id textRT @ev on April Fools - There is no Twitter Pro/text sourcelt;a href=http://iconfactory.com/software/twitterrificgt;twitterrificlt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user April Fools? -damon
[twitter-dev] Re: statuses/replies now include mentions
And is this available now via the JSON API interface because, according to my tests, I do not see any in the middle of a tweet mentions being reported by the API. Thanks - Martin On Mar 31, 1:33 pm, Joshua Perry j...@6bit.com wrote: This hasn't been said but I'm assuming this is only for tweets from this point forward, as I don't see any tweets from the past that mention my username... Doug Williams wrote: Devs, Before today calls to statuses/replies [1] would return only tweets that were prefixed with a @username. As clients began to recognize the value in mentions of a @username anywhere in the tweet, they opted to perform a search for @username to get the superset. Twitter agrees [2] that the definition of a reply has changed, and as such, calls to statuses/replies contain any tweets that include a mention of the authenticating user. If your client has been using the Search API to retrieve @replies, you should begin to migrate to statuses/replies method as it now best practice. 1.http://apiwiki.twitter.com/REST-API-Documentation#statuses/replies 2.http://blog.twitter.com/2009/03/replies-are-now-mentions.html Code on, Doug Williams Twitter API Support http://twitter.com/dougw
[twitter-dev] Re: API Changes for April 1, 2009
As of right right now: http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml On Apr 2, 3:34 am, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
On Thu, Apr 2, 2009 at 1:10 AM, Adrian spiritpo...@gmail.com wrote: As of right right now: http://twitter.com/users/show/bob.xml has about twice the amount of information as say: http://twitter.com/users/show/WeezerOfficial.xml FTA: Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. -Chad On Apr 2, 3:34 am, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: API Changes for April 1, 2009
From what method calls? On Wed, Apr 1, 2009 at 19:23, Damon P. Cortesi d.lifehac...@gmail.com wrote: I'm not sure if it's related to this push, but I've started to get several user objects back with no statuses_updates. This is a somewhat blocking bug for TweetStats as I try to verify they have tweets while verifying the account. Though I can just try to enumerate through and will probably have to do an emergency update to do so. here's a sample user object I'm getting back: ?xml version=1.0 encoding=UTF-8? user id20176857/id nameJonny Beasley/name screen_nameccfcrule/screen_name location/location description/description profile_image_urlhttp://s3.amazonaws.com/twitter_production/ profile_images/78298843/Me_With_Cap_normal.jpg/profile_image_url url/url protectedfalse/protected followers_count25/followers_count status created_atSat Mar 28 20:00:26 + 2009/created_at id1408524555/id textChecking out my TweetStats! http://tweetstats.com/graphs/ccfcrule/text sourcelt;a href=quot;http:// tweetstats.comquot;gt;TweetStatslt;/agt;/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name /status /user dpc On Apr 1, 5:34 pm, Alex Payne a...@twitter.com wrote: (Not an April Fool, we promise. We don't enjoy humor.) * Feature (REST API): We now return the same representation of User objects throughout the API. This representation contains all of the attributes we make available via the API. A bit more about this change: Previously, these full User objects were only available via the /users/show and /account/verify_credentials methods. If your application has been making requests to these methods just to get extra User attributes, you no longer need to do so. We've had many, many requests for these extra attributes to be available everywhere, so we hope to see you all making use of them! Please note that this new extended view of User objects may not appear for all users immediately. As cache expiry occurs for users in our system, the extra attributes will show up. Don't be surprised if this takes multiple days for inactive users. Please also note that if your application is operating in a highly bandwidth-constrained environment, you may want to proxy requests to strip out attributes that aren't relevant to your client. The additional bytes over the wire should not impact the vast majority of platforms, in our estimates. As always, you can keep up with these changes athttp://bit.ly/api_changelog. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: Getting a 401 when trying to get OAuth access token
I think you might be missing oauth_token from your access_token URL
parameter string in the snippet above, it should travel with the other
parameters and it its secret is hashed with the consumer secret in the
signature base.
It can be painful to solve whatever small deviation is causing your
problem, at least it was for me. My problem turned out to be that I
wasn't correctly parsing the oauth_token and oauth_token_secret out of
the response, so my code ended up taking a truncated version of the
token because it sometimes ended in '...', but it could be all kinds
of things.
Are you sending a source parameter in the mix and forgetting to hash
with it? Are you URL encoding at the right time? Are your parameters
in the right order according to the OAuth spec when you hash by name
=| value ?
On Apr 1, 7:08 pm, Troy Tolle tdto...@gmail.com wrote:
I am working on writing and OAuth client in Java for Twitter and I am
hitting the wall when trying to get the Access Token. I am able to
successfully get a sign and get a token, forward to the authorize
page, get a response, but after that, when trying to get the Access
Token, it dies. The following is my flow:
I am first sending a message with the following information to get the
token:
OAuthMessage(GET,http://twitter.com/oauth/request_token,
[oauth_consumer_key=RmhOF3YvERsY1uVF68tKg, oauth_signature_method=HMAC-
SHA1, oauth_timestamp=1238616948, oauth_nonce=1238616948972478000,
oauth_version=1.0, oauth_signature=itlw1V%2FSbJzHyU8VHs0wu4uMWew%3D])
This is the URL:
http://twitter.com/oauth/request_token?oauth_consumer_key=RmhOF3YvERs...
That seems to work great and I get back a response and a token:
[Date=Wed%2C%2001%20Apr%202009%2020%3A17%3A51%20GMT, Server=hi, Last-
Modified=Wed%2C%2001%20Apr%202009%2020%3A17%3A51%20GMT,
Status=200%20OK, ETag=%227b36526f344e3ae8dc0efa12532c71a9%22,
Pragma=no-cache, Cache-Control=no-cache%2C%20no-store%2C%20must-
revalidate%2C%20pre-check%3D0%2C%20post-check%3D0, Content-Type=text
%2Fhtml%3B%20charset%3DUTF-8, Content-Length=112, Expires=Tue%2C
%2031%20Mar%201981%2005%3A00%3A00%20GMT, X-
Revision=cac1726f8303dbd4844ed052d9f60f2118d51b8f, X-
Transaction=1238617071-29428-3892, Set-Cookie=_twitter_sess
%3DBAh7BzoHaWQiJTdjZDc4NDI5YzRmOTRmMDM5ODY2ODA4Njc0MmI1NjFlIgpm
%25250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%25250AOgpAdXNlZHsA--14ba7530dbc9101ea124fcf397ec1d3acd924c0b%3B
%20domain%3D.twitter.com%3B%20path%3D%2F, Vary=Accept-Encoding,
Connection=close]
Response Parameters:
{oauth_token=eKznWjog00qLi5VIWXKwWql89RyIRPuzKJHVKj0,
oauth_token_secret=secret is populated here}
Then, I use that Token to create the link to the Authorization page:
Twitter
Authenticationhttp://twitter.com/oauth/authorize?oauth_token=eKznWjog00qLi5VIWXKwWq...
After that comes back, I try to get the Access Token with the
following:
http://twitter.com/oauth/access_token?oauth_consumer_key=RmhOF3YvERsY...
This is where I am hitting the wall, because it is coming back as
unauthorized:
Access Token Response Headers:
[Date=Wed%2C%2001%20Apr%202009%2020%3A25%3A57%20GMT, Server=hi, Last-
Modified=Wed%2C%2001%20Apr%202009%2020%3A25%3A57%20GMT,
Status=401%20Unauthorized, Pragma=no-cache, Cache-Control=no-cache%2C
%20no-store%2C%20must-revalidate%2C%20pre-check%3D0%2C%20post-check
%3D0, Content-Type=text%2Fhtml%3B%20charset%3DUTF-8, Content-Length=1,
Expires=Tue%2C%2031%20Mar%201981%2005%3A00%3A00%20GMT, X-
Revision=cac1726f8303dbd4844ed052d9f60f2118d51b8f, X-
Transaction=1238617557-17087-17303, Set-Cookie=_twitter_sess
%3DBAh7BzoHaWQiJTZmMTA0N2RlNzUwZjhmY2ViY2U0Yzk5MjBhNDcwYjY4Igpm
%25250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%25250AOgpAdXNlZHsA--036987088c0603e72c0639000d32ea9cf1265fbe%3B
%20domain%3D.twitter.com%3B%20path%3D%2F, Vary=Accept-Encoding,
Connection=close]
{HTTP request=GET /oauth/access_token?
oauth_consumer_key=RmhOF3YvERsY1uVF68tKgoauth_signature_method=HMAC-
SHA1oauth_timestamp=1238617482oauth_nonce=1238617482950207000oauth_version=1.0oauth_signature=b
%2FInX%2BiBuMlREF99oFUeZYymuAg%3D
User-Agent: Jakarta Commons-HttpClient/3.1
Host: twitter.com
, HTTP status=401, HTTP response=HTTP/1.1 401 Unauthorized
Date: Wed, 01 Apr 2009 20:25:57 GMT
Server: hi
Last-Modified: Wed, 01 Apr 2009 20:25:57 GMT
Status: 401 Unauthorized
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-
check=0
Content-Type: text/html; charset=UTF-8
Content-Length: 1
Expires: Tue, 31 Mar 1981 05:00:00 GMT
X-Revision: cac1726f8303dbd4844ed052d9f60f2118d51b8f
X-Transaction: 1238617557-17087-17303
Set-Cookie:
_twitter_sess=BAh7BzoHaWQiJTZmMTA0N2RlNzUwZjhmY2ViY2U0Yzk5MjBhNDcwYjY4Igpm
%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%250AOgpAdXNlZHsA--036987088c0603e72c0639000d32ea9cf1265fbe;
domain=.twitter.com; path=/
Vary: Accept-Encoding
Connection: close
,
