Sometime this summer, use of Basic Authentication with the twitter API will be coming to an end. During the transition period, all of the third-party services that delegate calls have to stop using Basic Auth and will now have to use OAuth Echo for authorization.
Fortunately, OAuth Echo is pretty straightforward, with two catches that aren’t initially obvious but trivial to overcome. For reference, here is a link to the documentation of twitpic’s upload method.
http://dev.twitpic.com/docs/2/upload/
The two required headers are X-Verify-Credentials-Authorization and X-Auth-Service-Provider. The verify-credentials header is the same as a properly signed Authorization header pointed at the auth-service endpoint at twitter.
Herein lies the first snag that caught me. The current value used by twitpic is the following (not a clickable link):
https://api.twitter.com/1/account/verify_credentials.json
When signing the string for OAuth Echo, the URL you send in should be this, not the endpoint for twitpic (not https://api.twitpic.com/2/upload.json ).
The second snag that caught me was the HTTP method call. Calls to verify_credentials at twitter are GET, but calls to upload at twitpic are POST. The generated OAuth signature should use GET.
At first this didn’t make sense to me, but after some muddling about, I realize that this is about the easiest way for twitter’s third parties to be delegated control over a single call. The OAuth signature ensures that the only thing they can do at twitter is lookup credentials, and the middleman (twitpic) already has the work of generating the signature done for them by the client. The only thing that twitpic or others would have to do is copy the verify-credentials header into the authorization header when making the checkup call to twitter.
This is hardly just the first chapter, though, in what I expect will be further adventures in OAuth. The other, more important, API call at twitpic is the uploadAndPost call. This call, I speculate, is the root of where a ton of their homefront traffic is eventually generated. Right now, there is no equivalent OAuth Echo procedure that can allow twitpic to post to twitter. I’d imagine it isn’t too much effort (if any at all) to allow the twitter update-status method to be the target of the auth-service provider.
Some possible hijinks stand out with that particular method. One, is that the delegate may not necessarily be 100% trusted. Since the signer has already created a valid access token, the delegate could post content as it sees fit for that one call. It is unlikely anyone would do this, as that would open up a breach in trust, possibly causing them to lose access to twitter. There are some high-follow accounts where it may be worth it to a malicious insider to attempt this once, though.
Another potential issue is in error handling. Because a delegate is being used, the caller may be misinformed in a number of scenarios. The first is if twitter reports an error but succeeds, causing the delegate to report an error on the relayed call. The second is if the delegate fails internally after a call to twitter, leaving the potential result completely unknown to the caller. In recent times, under load, there have been gateway errors reported by twitter while API calls were actually succeeding; fortunately there were only two nights (that I recall) where this resulted in double-posts.
Last, it is unknown whether it will be possible to delegate by a single call to cover cases where the delegate needs to make several calls to the twitter api in a single unit of work. This will probably open up a number of questions as to whose API limit pays for the calls. I haven’t checked the results of rate-limit-headers yet, but I would guess that the client’s tally pays for the expense. This may not be good for delegates if they are performing tasks that might significantly cut into the caller’s hourly limit, which might make some clients wary of using their services.
