[twitter-dev] Re: The OAuth Conundrum
On Wed, May 6, 2009 at 18:05, MPS mpelzsher...@gmail.com wrote: I thought I'd add my $.02 to this thread. I'm working on an iPhone app that uses the Twitter API. This is a side project for me with a small budget and tight timelines. I'm using Matt Gemmel's Objective-C library to integrate with Twitter. Everything was going along smoothly, until I realized that in order to get Twitter to acknowledge my app (i.e. tweets from my app say from web rather than from [my app]), I need to use OAuth. (Older apps are being grandfathered in. How nice for them.) Matt's library doesn't support OAuth, and attempts by others to patch it have been less than successful. Feel free to check out the modifications I made for Adium: http://hg.adium.im/adium/file/tip/Plugins/Twitter%20Plugin/MGTwitterEngine This uses OAuth Consumer.framework and works pretty well. I don't know how well it translates over to the iPhone (the OAuth consumer part), but the OAuth details are ridiculously easy. Beware though, if you venture out of that folder you're going to have to GPL (that's where the OAuth token exchange, etc, happens. The example code on the OAuth website should help though). From my perspective, the requirement to use OAuth has added days of overhead to my project (blowing my estimates) and negatively impacted the user experience. I found I was able to do it in a few hours, really. For what it's worth, I agree completely with Josh; OAuth isn't adding value to anyone in this scenario. But it seems I've arrived too late to this party. :-( - Michael @zacwest
[twitter-dev] Re: http://twitter.com/direct_messages/new.json failed
On Fri, Apr 10, 2009 at 12:25, Doug Williams d...@twitter.com wrote: Gary, direct_messages/new requires a HTTP POST request. I can see from the URL you pasted in the post that you have a query string. If you are sending a POST request you would have no query string. Although, it is possible to have a POST with a query string, and doing so will generate the 401 error, even if it's a POST with a valid body. Took me a while to realize this is what was happening. Zac
[twitter-dev] OAuth and update_profile_image
Hi, It seems OAuth doesn't support multipart/form-data, at least this version of the OAuth spec doesn't support it. Would it be possible to also accept a base64-encoded, hashed (regular) argument for the image in the POST data instead of just the form-data submission/version? This would make it significantly easier to submit the data, if at all. Zachary West @zacwest
[twitter-dev] Open Source Applications and OAuth
Hi, I've got a question about how open-source applications are expected to behave under OAuth. In order to not violate the GPL, I am going to have to include my client and secret key in the application source available online. This would allow another client, spoofer, etc., to pretend to be Adium for the sake of gaining access, right? Is this the only major concern involved? I'm wondering if there's some kind of idea in place about how this might affect things. For example, if a second Adium request is presented, it's entirely possible that it's valid (since multiple computers might be used with Adium on it) so there's no way to say only one access for this Application is valid or anything like that. The OAuth website alludes to the fact that it might be a tricky situation for open-source apps, but says absolutely nothing about it, and that it may be a bad thing. Appreciate the response. Zachary West @zacwest
[twitter-dev] Re: update_profile_image gives me head ache
Hi Einar, You seem to be submitting your POST request incorrectly. This is how I (successfully) submit my update_profile_image: Content-type: multipart/form-data; boundary=BOUNDARYHERE --BOUNDARYHERE Content-Disposition: form-data; name=image; filename=FILENAMEHERE.png Content-Type: image/png (image) --BOUNDARYHERE-- Zachary West On Sat, Mar 14, 2009 at 14:46, Einar m...@einarsundgren.se wrote: I'm currently working on a c++ wrapper for the twitter API. Everything works smooth except uploading images. Both profile images and background images. The image I use is a png which already has been used as an Twitter avatar. So the response about a big image does not seem very likely. I send a HTTP-request that looks like this. Any idea why it won't work? POST /account/update_profile_image.xml HTTP/1.1 Host: twitter.com Accept: */* Accept-Language: en-gb User-Agent: Twittertester/01 Authorization: Basic ZgGreEmKxxClMy //No thats not my auth. No need to decode ;-) Connection: close Content-Type: multipart/mixed; boundary=limiter --limiter Content-Type: image/png Content-Description: Profile image Content-Transfer-Encoding: base64 iVBOR (... and so forth... A base64 encoded png image...) CYII= --limiter-- *** The response: * ?xml version=1.0 encoding=UTF-8? hash request/account/update_profile_image.xml/request errorThere was a problem with your picture. Probably too big./ error /hash **
[twitter-dev] Re: update_profile and the returned user information element
Hi Doug, @twitterapi said yesterday that it was a known issue they were working on, and today it appears to be working. Thanks anyway! Zachary West On Mon, Mar 9, 2009 at 15:29, do...@igudo.com wrote: Zachary, I tried a couple of different updates and didn't see the same behavior. Can you replicate and send headers, or give me steps to follow and replicate? Thanks, Doug Williams On Mar 8, 5:17 pm, Zachary West zacw...@gmail.com wrote: Hello, When POSTing an update_profile, the returned user information element doesn't actually contain the updated information; it contains the old values for the user. This doesn't seem quite right. I can understand it not being updated in other requests, caching and all, but can the response to the update contain the actual values which were accepted? Thanks, Zachary West
[twitter-dev] update_profile and the returned user information element
Hello, When POSTing an update_profile, the returned user information element doesn't actually contain the updated information; it contains the old values for the user. This doesn't seem quite right. I can understand it not being updated in other requests, caching and all, but can the response to the update contain the actual values which were accepted? Thanks, Zachary West
