making a twitter feed

posted by misterhaan in internet, php, track7, webdev on nov 9, 2010

i just finished (hopefully) the back-end work for tweeting track7 site activity. i’ve created a new static php class auSend which will be included in version 0.4.0 of my php auLib with three functions: Bitly(), Email(), and Tweet(). the one for sending e-mail is a wrapper around the php mail function with protections against spamming and doesn’t really apply to what i did with twitter.

the first thing i did, and probably the hardest, was to build the Tweet function. i needed it to tweet using a predefined twitter account taking only the message to tweet as a parameter. twitter makes you use oauth to prove who you are to the api before it will let you tweet that way, which is thankfully a little simpler if you only want to work with one pre-authorized account like i’m doing. i created a twitter account and then registered an application, which provides a pair of keys and secrets needed to let track7 automatically tweet new content.

i uploaded the same icon for the application that i had used for the twitter account (it’s the punk guy from the upper left of the site), but for some reason here it turned the alpha transparency black — oh well. i don’t think it really matters what you put in the fields when registering an application so long as you give it read and write access (i think the default is read-only). i named my application track7 and set its url to http://www.track7.org/ even though there’s no twitter-enabled application available for download there. once the application is created it shows consumer key and consumer secret. somewhere you get a token and token secret which are also needed, but i can’t seem to find those now — maybe it’s a one-time thing so make sure to save it off somewhere when you do see it.

the twitter api documentation is horrible. i couldn’t find a simple list of api urls to send requests to, or exactly what i had to do to make that oauth thing work. instead i found high-level explanations of the concepts. thankfully there’s a page about how you don’t need to implement the whole oauth flow if you’re working with one account (hey, that’s me!) which actually showed some simple code. of course that simple code used a php twitter library which in turn used an oauth library (track7 is all my own code so i wasn’t about to just download and use those) and was reading a twitter feed rather than posting to it. luckily i found the url i needed to post to somewhere else, so then i just had to read through the libraries and figure out what i need to do.

with the consumer key and secret and the token and secret (i think the “consumer” means the application and the “token" is tied to the user account) the oauth is relatively simple. you basically take all the stuff your request is going to send, generate a signature from that, and send the signature along with the request. the two secrets are used to create the signature, and the keys are send with the request. here’s what gets sent in the request, which by the way is a post to https://api.twitter.com/1/statuses/update.xml:

oauth_consumer_key
oauth_nonce
oauth_signature_method
oauth_timestamp
oauth_token
oauth_version
status

the oauth_consumer_key and oauth_token are always those values you get from authorizing the application. oauth_nonce i read somewhere in the twitter api documentation needs to be a unique value for each request. the php oauth library i looked through used md5(microtime() . mt_rand()) to generate a unique value, which seemed like a good enough way to do it for me. oauth_signature_method and oauth_version are always HMAC-SHA1 and 1.0, so those are easily hard-coded. oauth_timestamp wants a unix epoch timestamp, which is exactly what php’s time() gives us, so that’s easy. status is the thing you actually want to tweet, and the only one of these that needs to be url encoded since it could be anything. i used rawurlencode() for this, which uses % codes for any characters that would mess things up. also note that these value names are in alphabetical order — the documentation said you need that for when you create the signature.

put all that into a query string format (name1=value1&name=value2, etc.), which will go toward generating the signature and then along with the signature be sent as the post data for the request. now the whole thing needs to get url encoded (so rawurlencode() again), and added to the end of POST&<encoded url>&. the POST there is actually just as you see it there, and the <encoded url> part is the url the request is going to passed through rawurlencode(). i gave that url earlier.

if you’re like me you probably don’t know what an HMAC-SHA1 signature is. i figured out how to do it based on the oauth library code. you take that POST&... string from before and pass it as the second parameter to hash_hmac() with 'sha1' as the first parameter, and the two secrets as the third parameter, and true for the fourth parameter. the secrets get put together in a string as the consumer secret followed by an & followed by the token secret. the fourth parameter means raw output, which we want because the next step is to base64-encode it with base64_encode(). what comes out of that function is the value that needs to be sent as oauth_signature with the request. rawurlencode() this value since it can contain an equals sign, and then stick it on the end of that query string from before as the value for oauth_signature. now it’s as simple as using curl to send the post request.

twitter will of course send back results (i got a few error messages while figuring things out) as the response body. since the url i use ends in .xml, the results come back in xml format. they also support json if you change the end of the url from .xml to .json, but i don’t think i’ll be interpreting the results anyway.

so with a working Tweet function to post tweets from my site, i figured i should look into using the bit.ly url shortening service so i could have a little more room to actually say stuff in my tweets. this time i didn’t need to mess around with oauth, but the bit.ly api documentation is apparently incorrect. after trying to use the query parameters in the documentation and getting nowhere, a quick google search showed me that where the documentation said to use longUrl, x_login, and x_apiKey, i actually needed to use uri, login, and apiKey. once you sign up for a bit.ly account and get your api key, it’s pretty easy to use curl to send a get request to http://api.bit.ly/v3/shorten?login=<username>&apiKey=<key>&uri=<encoded url>&format=txt and then use the result as the shortened url. you can alternately use xml or json as the format and have to dig the url out of that, but txt gets you just the url (or an error message if you’re sending the wrong parameters) as the response so it’s easier.

now that i have those functions working along with a separate file that holds my keys and secrets, i can have my site call auSend::Bitly($url) to get a shorter url and slap that on the end of a message i can post to twitter with auSend::Tweet($message). all i have to do now is figure out when i want that to happen and come up with short enough messages . . .