Andy's Blog

How to Build an OAuth Consumer

2009-03-12T20:43:00.000-07:00

Introduction

I just read a magnificent blog post from Joseph Smarr over at Plaxo that inspired me to share some of my experiences in helping to build and test TripIt's OAuth protected API.

I've written this post as a guide that lets you manually walk through all of the steps an OAuth consumer must implement in order to be able to make authenticated calls to TripIt's API. At each step of the process I've referenced a set of command line utilities that you can use to run through the examples as well as explanations for what those utilities are doing under the covers. All of these utilities can be found in TripIt's Python binding/wrapper library here:

http://groups.google.com/group/api_tripit/web/tripit-api-language-bindings

The Python binding for the TripIt API is actually a complete OAuth consumer implementation in addition to a convenient wrapper for the TripIt API. The command line utilities in this package enable you to conveniently execute each step of the OAuth authorization process from the command line. I recommend you go through this process a few times by hand as it should help you (it definitely helped me) get your head around all of the different steps involved in getting a user to authorize your application. Note: executing any of these commands w/o command line arguments will print a useful usage message.

With the specific example I walk through in this document I've included all of the public and private portions of all request and access tokens as well as the consumer key and secret. If you need to re-implement an OAuth consumer in another language you can use the inputs and outputs for each step of the process in this post to test your code to see if your code is working.

Also, please note that the discussion is very TripIt focused. While we implemented the provider to the specification we didn't implement everything (e.g. the only signing algorithm we built was HMAC-SHA1).

To frame the overall discussion, imagine the requests coming from a consumer application (Alice) and a content publisher (Bob). OAuth channels the authentication for this dialogue in a highly stylized way.

Alice: I would like to develop a TripIt application. [Registers application]

Bob: Thanks. Here are the permanent Consumer Token and the Consumer Secret values for that application.

Alice: Now, I would like some private information from you about trips. Here is my Consumer Token and Secret. Also, since an eavesdropper might try to replay my request later, I'll also add a random Nonce and a Timestamp. Finally, I have signed this request in a very specific way.

Bob: Everything is in order here, thanks. Here is an Unauthorized Request Token, good for one use only.

Alice: The user must ok the next step. Browser, here's a url with that Unauthorized Request Token, plus a Callback URL argument.

Web Browser: Tripit, here's that URL.

[User logs in & grants access. ]

Bob: All is good. I'm creating an Authorized Request Token, valid just for that user and your application. Now I'm redirecting to the callback URL.

Alice: Here's my Consumer Token and Secret as well as my Request Token and Secret. Give me the Authorized Request Token and matching Secret you just generated, please.

Bob: Here they are.

Alice: Sweet. All future requests from me will have the four values:

Consumer Token

Consumer Secret

Authorized Request Token

Authorized Request Secret

Bob: We stand ready for all your travel information needs.

Although simplified to an extreme degree, this shows the fundamentals of the protocol.

Before getting started I wanted to give a shout-out to my colleague Travis W. who's a very smart guy that didn't know anything about OAuth before helping me proof-read this post. He contributed the idea for the OAuth discussion you just read and claims this run-through helped him wrap his head around how to write a consumer. I hope he wasn't just being nice. Let's get started!

Getting an Unauthorized Request Token

The first step is to get an unauthorized request token. An unauthorized request token is just a string that enables an OAuth consumer to "ask" a user to grant it an authorized access token. To get an unauthorized request token a consumer must have a consumer key and secret. To generate a set of these to work with the TripIt API you simply go through the process of creating an application here: http://www.tripit.com/developer (Note: you must have a TripIt account to do this but that's free so what's stopping you?!).

IMPLEMENTATION NOTE: You need to store the the consumer key/secret somewhere so that your application can get to them everytime it needs to generate a new request token or obtain an authorized access token.

For this example I'm going to use the following consumer key/secret:

Key:	5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc
Secret:	fceb3aedb960374e74f559caeabab3562efe97b4

Once you have your consumer key/secret you can use the get_request_token.py command to generate a new request token like this:

$ consumer_token=5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc
$ consumer_secret=fceb3aedb960374e74f559caeabab3562efe97b4
$ python get_request_token.py https://api.tripit.com $consumer_token $consumer_secret
RESPONSE: oauth_token=df919acd38722bc0bd553651c80674fab2b46508&oauth_token_secret=1370adbe858f9d726a43211afea2b2d9928ed878

Here is what the get_request_token.py script is doing under the covers:

In order to make any OAuth request a consumer must know how to properly form the request. The first part of understanding how to form a proper request is understanding what request parameters are required. Here is a list of all OAuth the request parameters, what they represent, and how to generate them:

oauth_nonce

A nonce is just a Number you use ONCE. That's actually a bit of a misnomer because a nonce doesn't really need to be a number at all. It just needs to be a random and globally unique string. The nonce is used along with the timestamp to uniquely identify each request made to an OAuth provider and helps the provider detect whether or not an attacker is trying to "replay" an intercepted API call. For a more in-depth description of the security risks around a replay attack check out Eran Hammer-Lahav's post on OAuth security architecture.

The OAuth consumer code in the TripIt library creates nonces using the OAuthConsumer::_generate_nonce() method from tripit.py by computing the hex form of an md5 checksum on a concatenated string that contains the current epoch time in seconds plus a string of 40 random numbers between 0 and 9. For those who read Python:

    def _generate_nonce(self):
        random_number = ''.join(str(random.randint(0, 9)) for i in range(40))
        m = md5.new(str(time.time()) + str(random_number))
        return m.hexdigest()

The important thing to make sure about the code you write to create the nonce is that it will not generate the same string more than once across all requests.

oauth_timestamp

The timestamp is just the integer representation of the number of seconds since the epoch. It's used in conjunction with the nonce to make sure the API doesn't respond to requests that have already been made.

oauth_consumer_key

The consumer key is the string you obtained when you registered your application with the OAuth provider. In TripIt's case you can do that here: http://www.tripit.com/developer. In the example we are working through here the consumer key is:

5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc

oauth_signature_method

The OAuth spec allows for 3 different signing algorithms (i.e. HMAC-SHA1, RSA-SHA1, and PLAINTEXT). TripIt only supports HMAC-SHA1 and so that is the only signing algorithm I am going to describe in any detail.

oauth_version

At this time there is only one version of the OAuth specification (version 1.0). Therefore, the value of the version parameter should be "1.0".

oauth_signature

The signature is where most people who are trying to make an OAuth request run in to trouble. In order for a signature to be "valid" both the consumer and provider must implement the same signing algorithm so that when the provider re-computes a signature for a request it matches exactly the one posted to it in the request by the consumer. If they is even a single character difference, the request will fail with a 401 "Invalid Signature" return code.

Here's a description of the algorithm used to generate a signature (all of this is documented in code in the tripit.py implementation of OAuthConsumer::generate_oauth_parameters() so you can follow along if you read Python):

Collect all request parameters

The first step in computing a signature is to collect all the parameters in the request. All parameters means all of the oauth_* parameters (i.e. oauth_consumer_key, oauth_nonce, oauth_timestamp, etc...) plus any parameters that are part of either the query string and/or the body of a POST request (e.g. xml= or json=). The implementation in tripit.py simply creates a Python dictionary with all the OAuth parameters and combines those with the args in the query string (i.e. url_args) and the POST body (i.e. post_args):

parameters = self._oauth_parameters

if url_args is not None:
    parameters.update(url_args)

if post_args is not None:
    parameters.update(post_args)

Normalize the request parameters

According to the OAuth spec all request parameters must be sorted using lexicographical byte value ordering, url encoded, and then concatenated together with an '&' separating each value. Here's the code from tripit.py that does this:

normalized_parameters = self._escape('&'.join(['%s=%s' % (self._escape(str(k)), self._escape(str(parameters[k]))) for k in sorted(parameters)]))

So, in English:

Sort the parameter dictionary by key name (Note: I'm not concerned about redundantly named keys in this implementation because it's not a concern for TripIt. If you needed to consider this the OAuth spec says sort by parameter name and for parameter names that are equivalent, sort by value)
URL Encode each key/value pair
Create a list of <key>=<value> pairs and join them all together with &'s
URL encode the whole thing

Construct the signature base string

Take the sorted, escaped, and concatenated list of URL parameters you just generated and prepend to it the normalized HTTP method name and URL all separated by '&'. Here's the code that generates the signature base string:

signature_base_string = '&'.join([normalized_http_method, normalized_http_url, normalized_parameters])

The normalized HTTP method is simply the HTTP method (i.e. GET or POST) in all caps. The normalized HTTP URL is the resource URL in your request, URL encoded. Here is what the signature base string looks like in this example:

POST&https%3A%2F%2Fapi.tripit.com%2Foauth%2Frequest_token&oauth_consumer_key%3D5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc%26oauth_nonce%3D39100e296c709a592600c8d1a3ee69dd%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1235272437%26oauth_version%3D1.0

Generate a key

Up until now all the consumer has done has been to format the "non-secret" portions of the request. The consumer must now generate a key that it will ultimately use to compute the signature. For API requests such as the one to get an unauthorized request token, the key is simply the oauth_consumer_secret followed by a single '&'. For API requests for protected resources that are being made after an authorized access token has been obtained, the key is the oauth_consumer_secret and the authorized oauth_token_secret separated by a '&'. Here's what the key looks like for the request to get an unauthorized request token in this example:

fceb3aedb960374e74f559caeabab3562efe97b4&

Compute the oauth_signature

Once you have the signature base string and the key, it's time to compute the signature. The signature will be sent to the provider with the request and if all goes well the provider will go through an identical set of steps to re-compute the signature. If you did your job right, the signature string the provider computes will be an exact match for the one computed by the consumer. TripIt only supports HMAC-SHA1 so here's some Python code that does that for you:

try:
    import hashlib
    hashed = hmac.new(key, signature_base_string, hashlib.sha1)
except:
    import sha
    hashed = hmac.new(key, signature_base_string, sha)

self._oauth_parameters['oauth_signature'] = base64.b64encode(hashed.digest())

For our example, the value of the signature is:

KlTlU95CdzFYo5tfrJjaPz5RA6g=

Once all the OAuth parameters are generated you will need to construct an HTTP Authorization header to send along as part of the request. The OAuth specification says in section 5.4 that the Authorization header is the preferred authorization scheme and it's the only one that TripIt supports. Here's what the authorization header looks like for this example:

Authorization: OAuth realm="https://api.tripit.com",oauth_nonce="39100e296c709a592600c8d1a3ee69dd",oauth_timestamp="1235272437",oauth_consumer_key="5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc",oauth_signature_method="HMAC-SHA1",oauth_version="1.0",oauth_signature="KlTlU95CdzFYo5tfrJjaPz5RA6g%3D"

In Python, using the urllib2 library, you add the header to the request like this:

request.add_header('Authorization', authorization_header);

If all goes well the server responds with an unauthorized request token as well as the unauthorized request token secret. The consumer's job is now to have the user authorize those request tokens. Here's what the response from the server looks like:

oauth_token=df919acd38722bc0bd553651c80674fab2b46508&oauth_token_secret=1370adbe858f9d726a43211afea2b2d9928ed878

IMPLEMENTATION NOTE: You need to store these values someplace where your application can retrieve them so that you will be able to retrieve the authorized access token later on. For this example, save the values you get from get_request_token.py as you'll need them to continue following this example.

Authorizing an Unauthorized Request Token

You've just completed the process of obtaining an unauthorized request token and secret. This token is only good for one purpose and that is to enable the consumer to ask the user to grant it an authorized access token. To mimic this part of the process you will need a web browser. When building an OAuth consumer the call to TripIt's API is usually immediately followed by an HTTP redirect to the following URL:

https://www.tripit.com/oauth/authorize?oauth_token=df919acd38722bc0bd553651c80674fab2b46508&oauth_callback=http%3A%2F%2Fwww.tripit.com%2Fhome

Naturally the specific value of the oauth_token depends on what you received when you requested a request token. The value of the oauth_callback is usually a URL in your application that implements the code I will talk about in the next section to download the authorized access token.

To mimic the behavior of your application, just go to the above URL w/ your web browser. Make sure to replace the value of oauth_token with whatever you got from get_request_token.py in the last section!

If you aren't logged in to TripIt when you access the URL you will be prompted to do so. Once logged in you'll see a screen that looks like this:

Click the 'Grant Access' button and notice that you are redirected back to http://www.tripit.com/home (i.e. the oauth_callback URL). The provider now has an authorized access token for your consumer and all you need to do is go and get it!

Obtaining the Authorized Access Token

Congratulations, you're nearly ready to start querying the API! All that's left to do is get the authorized request token and then use it. To obtain the authorized access token the TripIt Python binding package has another utility called get_authorized_token.py that can help you mimic what an OAuth consumer does to download the authorized access token after a user has clicked the 'Grant Access'
button on the /oauth/authorize page and has been redirected back to the consumer application. Here's what a sample run of the get_authorized_token.py utility looks like:

$ consumer_token=5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc
$ consumer_secret=fceb3aedb960374e74f559caeabab3562efe97b4
$ request_token=df919acd38722bc0bd553651c80674fab2b46508
$ request_token_secret=1370adbe858f9d726a43211afea2b2d9928ed878
$ python get_authorized_token.py https://api.tripit.com $consumer_token $consumer_secret $request_token $request_token_secret
RESPONSE: oauth_token=b865676c95c736c4cbb90c652cd896dec022ba86&oauth_token_secret=f3ce720ebb4c0ddc3469662c246f78ef4d99f1cb

IMPLEMENTATION NOTE: Save the authorized access oauth_token and oauth_token_secret values somewhere your application can get to them. You will need them to make API calls! It is now safe to discard the request token and token secret you obtained earlier.

The process of getting the authorized access token is exactly the same as getting a request token except for two things. First, the oauth_token_secret of the request token is included in the request parameters and therefore in both the signature base string and the key used to sign the request. This means that the
signature base string for this request looks like this:

POST&https%3A%2F%2Fapi.tripit.com%2Foauth%2Faccess_token&oauth_consumer_key%3D5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc%26oauth_nonce%3D45a4e8dc2000e5c3fb27aefeb4769326%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1235272542%26oauth_token%3Ddf919acd38722bc0bd553651c80674fab2b46508%26oauth_token_secret%3D1370adbe858f9d726a43211afea2b2d9928ed878%26oauth_version%3D1.0

Note the inclusion of the oauth_token_secret parameter. When generating the key that's used to create the oauth_signature parameter it should look like this:

fceb3aedb960374e74f559caeabab3562efe97b4&1370adbe858f9d726a43211afea2b2d9928ed878

The string after the & is the oauth_token_secret obtained along with the unauthorized request token.

The second difference is the URL you request the authorized access token from is https://api.tripit.com/oauth/access_token.

Aside from those two relatively minor differences, the process of requesting an authorized access token is identical to that of requesting the request token. token.

Using an Authorized Access Token

If all went well, your application now has an authorized access token that can be used to make API calls. While it's beyond the scope of this post to document the TripIt API, let's go through a simple example so you can see how to form an OAuth request properly. For a complete description of all the methods and their return
values you should check out TripIt's API documentation. Here:

http://groups.google.com/group/api_tripit/web/tripit-api-documentation---v1

To form a simple request to get a user's upcoming trips you would make a GET request to the protected resource URL: https://api.tripit.com/v1/list/trip.

To mimic this request on the command line use the make_request.py utility included in the TripIt Python library. Here's what a sample run of the make_request.py utility looks like:

$ consumer_token=5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc
$ consumer_secret=fceb3aedb960374e74f559caeabab3562efe97b4
$ auth_token=b865676c95c736c4cbb90c652cd896dec022ba86
$ auth_token_secret=f3ce720ebb4c0ddc3469662c246f78ef4d99f1cb
$ python make_request.py https://api.tripit.com/v1/list/trip $consumer_token $consumer_secret $auth_token $auth_secret 
RESPONSE: <Response><timestamp>1235272610</timestamp><Trip><id>1180136</id><relative_url>/trip/show/id/1180136</relative_url><start_date>2010-01-21</start_date><end_date>2010-01-30</end_date><display_name>Honolulu, HI, January 2010</display_name><image_url>http://www.tripit.com/images/places/general.jpg</image_url><is_private>true</is_private><is_traveler>true</is_traveler><primary_location>Honolulu, HI</primary_location></Trip></Response>

Under the covers, a request to a protected resource is basically the same as that to obtain an authorized access token. By now you should be very familiar with how an OAuth request works so I'll just describe the core components used to generate the request. Here's the signature base string:

GET&https%3A%2F%2Fapi.tripit.com%2Fv1%2Flist%2Ftrip&oauth_consumer_key%3D5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc%26oauth_nonce%3D720201c8b047528e4fcc119a98cffc8e%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1235272610%26oauth_token%3Db865676c95c736c4cbb90c652cd896dec022ba86%26oauth_token_secret%3Df3ce720ebb4c0ddc3469662c246f78ef4d99f1cb%26oauth_version%3D1.0

Note that since you are asking for upcoming trips and that's done via an HTTP GET to the URL https://api.tripit.com/v1/list/trip the signature base string starts out with a 'GET'.

The key, like the one used to sign the request for an authorized access token, includes both the oauth_consumer key and authorized access token oauth_token_secret. It should look like this:

fceb3aedb960374e74f559caeabab3562efe97b4&f3ce720ebb4c0ddc3469662c246f78ef4d99f1cb

The Authorization header should look like this:

Authorization: OAuth realm="https://api.tripit.com/v1/list/trip",oauth_nonce="720201c8b047528e4fcc119a98cffc8e",oauth_timestamp="1235272610",oauth_token_secret="f3ce720ebb4c0ddc3469662c246f78ef4d99f1cb",oauth_consumer_key="5dbf348aa966c5f7f07e8ce2ba5e7a3badc234bc",oauth_signature_method="HMAC-SHA1",oauth_version="1.0",oauth_token="b865676c95c736c4cbb90c652cd896dec022ba86",oauth_signature="QlHuyGIbtPNNra7qBEAcdbqQuGc%3D"

And the response will be an XML document that looks like this:

<Response>
    <timestamp>1235272610</timestamp>
    <Trip>
      ... XML that describes a Trip ...
    </Trip>
  </Response>

Conclusions

Congratulations, you've gone through the OAuth authorization flow and learned how to build an OAuth consumer that implements that flow. Implementing an OAuth consumer can be a slightly tedious task as there are a number of steps and all have to be executed very precisely to guarantee success. I highly recommend that you use the command line utilities provided with the TripIt Python library and go through the process a couple of times until you really understand the order of events and what each step means before you go trying to implement an OAuth consumer on your own. Once all of the steps are in your head, implementing them should be relatively
straightforward.

Good luck!

Crypto Nerd World

2009-02-10T13:57:00.000-08:00

Courtesy XKCD: http://xkcd.com/538/

What Every American Wants to Say Right Now

2009-02-06T09:36:00.000-08:00

If every American had the same platform to talk to regulators and the folks in the last administration that were getting paid to keep an eye on things and make sure the economy didn't go off the rails due to gross negligence and corrupt behavior, this about what I imagine most of them would say.

Absolutely classic. I'm only slightly disappointed he restrained himself as much as he did. Go Gary!

AJAXWorld Presentation Finally Posted

2008-11-18T19:34:00.000-08:00

I just got around to posting my presentation from AJAXWorld. Sorry it took so long, enjoy.

Building Email Apps

View SlideShare presentation or Upload your own. (tags: ajaxworld email)

I Screwed Up and I'm Sorry

2008-10-28T23:18:00.001-07:00

Speaking at AJAX World Tomorrow

2008-10-19T22:19:00.000-07:00

I'll be at AJAX World tomorrow talking about email and how to build compelling applications on top of it. Should be fun, if you're there, please stop by!

TripIt Blog Badge

2008-10-01T22:22:00.000-07:00

TripIt launched a new blog badge a few weeks ago. I installed it on my blog (of course!) and even though I am biased, I think it looks really nice and is a great way for you to keep your readers up to date with your travel schedule even if they don't have a TripIt account. If you do have a TripIt account just go here and enable the blog badge. If you don't have a TripIt account and you travel a lot, what are you waiting for? Go sign up!

Win an iPhone Because I Can't

2008-08-13T19:50:00.000-07:00

WARNING: this is a shameless plug for TripIt, but what the hell.

We just launched a "contest" in which you can refer friends to TripIt and be entered into a drawing for some pretty cool prizes. The more friends you refer, the more chances you have to win! The grand prize is a brand-spankin' new 3G iPhone. Unfortunately, I'm not qualified to win and even if could win everyone I know already uses TripIt anyway. :)

So, tell a lot of people about TripIt often!

For more details follow this link:

http://www.tripit.com/promo/referSummary

The Rise and Fall of Twitter

2008-08-08T10:18:00.001-07:00

I was highly offended and thought it best to share. :)

The Last Journey of a Genius

2008-07-23T22:02:00.000-07:00

Pure genius. I hope you all enjoy it as much as I did.

Obviously This Show Needs to Get Made

2008-05-18T18:41:00.000-07:00

Fun with GreaseMonkey and the Future of Email Apps

2008-05-01T21:29:00.000-07:00

A few months ago I hacked (I mean literally hacked, it ain't pretty :) up a little GreaseMonkey script called TripIt For GMail. The idea was to play around with the concept of embedding TripIt functionality inside a mail client. Since the GMail team are supporters of GreaseMonkey and have created an "API" for GreaseMonkey scripts within the GMail UI I decided to start there.

The script is extremely simple. All it does is embed an 'Add to TripIt' button in the right hand column of the GMail web UI.

Currently the script does not even attempt to decide whether or not the email you are looking at is a travel confirm (that's something one could imagine adding pretty easily). Also, because it's just a GreaseMonkey script and not a true application running inside of GMail it doesn't have access to the source of the mail message and therefore needs to automate the actions of a user clicking on the 'Forward' button, typing in plans@tripit.com and hitting 'Send'. Clever, but not how I really want to build this app.

I haven't had much time to work on the script since January as I've been pretty busy but I did just post it to UserScripts here for anyone who is interested in playing around with it. It's only been tested on Firefox 2 on Linux, Windows, and Mac so if you're using FF3 or FF1 your mileage may vary.

More important than the actual implementation of this script is the direction I see email clients and platforms heading. Imagine an email system that is smart enough to detect what you were looking at and automatically do intelligent stuff for you. In the use case that is currently near and dear to my heart the system figures out that the email you are looking at (or maybe you don't even have to look at it :) is a travel confirmation, sends the source of that email to TripIt (ideally via a RESTful API authenticated via oAuth) so that a beautifully formatted itinerary gets created for you. Take that one step further and imagine the email platform re-consuming that data from TripIt in any one of a number of forms (e.g. iCalendar, RSS/Atom, API, etc...) so that all of it is re-integrated into your suite of productivity web/desktop apps in semantically intelligent ways. The system should do all the work for you so you can focus on where you're going and what you have to accomplish once you get there (i.e. your "real" work).

In the travel space TripIt has been driving the use of email as a critical component of what I humbly think is a very useful social travel organizer for folks who travel. Beyond travel however, there are tons of useful applications (both social *and* non-social) for this kind of intelligent platform and trying to inspire folks to create these applications was a focus of my talk at the Web 2.0 Expo here in San Francisco.

I think the message is getting through and I think folks are finally realizing that email always has been and continues to be a great interface to systems, humans, and your data. Folks such as Boris Veldhuijzen van Zanten over at NextWeb, Jake Kuramoto at Oracle, and Mark Hendrickson at TechCrunch understand and have talked about the possibilities.

The time is right, and long overdue, for intelligent apps built on top of good old fashioned, ubiquitous, and highly scalable email to begin seeing the light of day. In the coming months I hope we start to see companies like Yahoo and Google open up their mail platforms and turn them into application platforms. We've already seen Yahoo begin opening up their search results page with SearchMonkey and the best information is that he rest of Yahoo, including mail, is going in that direction as well.

In smaller ways it appears as if this trend is already beginning with the beta launch of webmail provider Zenbe. I haven't actually seen the Zenbe yet but if it works as advertised, this is a great model for where mail platforms should be going. There are also companies such as Xobni who are nicely positioned to chip away at this problem from the client side of what is probably the most widely deployed email platform in the world (at least in corporate settings), Outlook/Exchange. It would be nice if Microsoft's Exchange group were focused on this but so far I've seen no indication from the sleepy giant in Redmond that they are thinking along these lines. Of course there are a lot of smart folks up there so I wouldn't be surprised if someone is trying to fight what must be a significant amount of corporate inertia to get this done, who knows. It's definitely a huge opportunity for them given their dominant market position in corporate email infrastructure.

I can't wait to see this continue to unfold, it's going to be an interesting year!

Ooops...

2008-04-26T18:46:00.000-07:00

Web 2.0 Presentation

2008-04-25T09:12:00.001-07:00

I made the slides for my Web 2.0 Expo preso available via Slideshare and embedded them on the TripIt blog. Enjoy!

Speaking at Web 2.0 Expo

2008-04-21T23:55:00.000-07:00

If you'll be attending Web 2.0 Expo in San Francisco, I will be giving a talk entitled Making Email a Useful Web App on Wednesday (4/23). Should be a fun, and I hope informative, discussion. Drop by if you can!

TripIt Nominated for a Webby!

2008-04-10T16:12:00.000-07:00

Like everyone else I've been following the Webby's for years but never in a million years imagined I'd be a part of a company that was nominated for one. If you guys were planning on voting and like TripIt, please don't be shy, vote now! Vote here! (registration required)

Solved: iMac Wireless Issues

2008-03-29T22:34:00.000-07:00

It's been a few weeks since I purchased a NetGear RangeMax router I haven't had a single problem with the iMac. My apologies to Apple but it seems like my old Linksys didn't have what it took to sufficiently cover the apartment.

In other news, I finally upgrade my main laptop from Dapper Drake to a beta version of Hardy Heron and it rocks!

Update: iMac wireless w/ DD-WRT

2008-02-24T12:32:00.000-08:00

Impressive, I boot up the iMac this morning and it immediately connected to my non-SSID broadcasting wireless network. A sign of good things to come, I hope... If so, I may have to begin writing an apology to Apple.

Just Installed DD-WRT

2008-02-23T15:14:00.000-08:00

I just hacked my Linksys router and installed dd-wrt so I could boost the signal strength of the device. Btw, for anyone who has been considering doing this but has not because you were afraid of bricking your router, I had no issues with the install process. I have a WRT54G v2 router which is pretty old and as such very well supported so your mileage may vary, but I had no issues.

I have been suspecting for a while now that my rants at Apple have been misplaced and that the true nature of my wireless problems have more to do with the distance between the new iMac and the router. We'll see, but either way dd-wrt has all kinds of neat features that the stock Linksys firmware did not have so I will have plenty to play with this evening.

New Look for the Blog

2008-02-20T21:53:00.000-08:00

I didn't really like how narrow the template I was using was so I'm playing around with a new look. So far so good.

Tabs v. Spaces

2008-02-14T17:18:00.000-08:00

It's unfortunate that it has been so long since I last posted but I have been really busy both personally and professionally. I re-ran across this today as I was searching for a solid PHP mode for Emacs (I finally ditched Eclipse and PHPEclipse as my PHP development environment as it was too slow and my threshold for pain was finally surpassed).

http://www.jwz.org/doc/tabs-vs-spaces.html

Absolutely classic! Let the religious wars begin...

Enjoy and Happy Valentine's day.

Supreme Nerd God

2008-01-14T17:59:00.000-08:00

If NerdTests.com says it, I have to believe it.

The iMac is Wired

2008-01-14T09:45:00.000-08:00

I have given up for now trying to get the wireless on the iMac to be stable. Of course the problems might be related to my access point (standard Linksys WRT45G), the distance from the machine to the access point, hardware issue, or radio interference of some kind. Of course my Ubuntu box is sitting right next to the Mac and having no problems so I don't really believe the problems have anything to do with anything but the Mac itself. So for now I've hardwired the Mac to the network so I can get some work done.

Next steps are to wait for the next Leopard update (I hear it's coming out soon). If that doesn't work, I will give Apple customer support a spin to see if it's as good as folks claim. If those two things don't work I might try a different access point. I know folks who have the NetGear RangeMax and have had good success, maybe I'll try one of those. So disappointing...

2007 a Year in Review

2007-12-31T15:08:00.001-08:00

Just kidding, I hate those new year roundup/prediction posts. Stop reading blogs, turn off your computers and go have some fun, it's New Years Eve! Happy New Year everyone!

A Few Weeks with an iMac

2007-12-29T21:42:00.000-08:00

I've had the iMac now for a few weeks and thought I'd give some of my first impressions of the machine. I really like the machine. It's the first Mac I've owned and it's the only computer that I've ever owned that I could see being described as "sexy." The physical design of the machine is beautiful. It feels solid, is quiet, takes up a minimal amount of space (important in a San Francisco apartment), and is very fast. Apple has done a wonderful job of making the experience of owning a Mac from the time you open the box to the time the machine is up and running a really great one. Compared to the pain I had when I set up a Vista box at work a few months back, the iMac was a cinch and I was up and running within 30 minutes (including un-boxing and physical setup). Compare this to Vista where I spent the same amount of time un-boxing the machine, and then the rest of the day removing all the crapware Dell was gracious enough to install for me, this was a dream. The only thing Apple tried to sell me was a .Mac membership. I politely declined and was never bothered again. I really appreciated that as it was obvious that someone spent time thinking about *me* (the person that just forked over his hard earned money to buy this machine) as I was going through this process. It may sound weird, but I'd almost describe it as thoughtful.

As for the machine itself, I'd say it's been an OK experience so far. I don't say "great" because while the gear is nice and I was up and running quickly, Leopard isn't quite ready and hasn't been as stable as my Dell laptop running Ubuntu Linux. I've had a few Leopard kernel panics that I have been unable to figure out and the wireless support is embarrassingly bad. To be fair, the kernel panics seemed to have subsided since I installed the 10.5.1 "patch" for Leopard and the machine does seem a bit more stable now.

Above all, the one thing that has surprised me more than anything is the lack of reasonable support for "secured" wireless networks. My network at home was set up with a 128 bit WEP key (not too secure but I change it on occasion and it's better than nothing), is not broadcasting its SSID (why would I?), and is MAC limited to only my machines. I have *never* had a problem with my Linux box finding my wireless network. Granted, with Linux, you generally need to find the right driver/gear combination to get a stable system, but once I sorted that out, it has been rock solid for me.

The wireless support has been a nightmare. Every time I booted the machine it would forget the SSID of my network. Seriously? So, I re-provide the SSID and the password and then maybe it would attach successfully to the network 1 in 10 times. I even had this type of problem after waking the machine from sleep. Come on, the ability of a Mac to go to sleep and come up right where you left it is legendary! After a few times dealing with this I decided that I needed to figure out what was going on. So, I did some experiments.

The first thing I changed was to remove the wireless security and WEP password. This made absolutely no difference to how the machine behaved. The next thing I did was to broadcast my SSID. Sadly, this seems to have made things more stable. I say sadly because now my network SSID is being broadcast to the world. It's not so much that I am worried that the black van with the tinted windows is going to pull up outside my house to steal bandwidth and passwords (I am a heavy user of SSH and SSL), but I am pretty amazed at how poor a job Apple did making sure Leopard was "right" before they released it. Isn't this the company that hates buttons and wires? Are they subtly encouraging me to wire up? :)

Ok, enough grumpiness for one night. Apple will be coming out with another multi-hundred GB patch for Leopard shortly. I'm hoping they will sort these issues out.