Did you even know DotNetOAuth existed? It’s alpha quality right now but that will change soon. OAuth and OpenID serve two orthogonal needs, and although Google is trying to combine the two, I haven’t figured out how they are going to do it yet. In the meantime I have been writing the DotNetOAuth library for you .NET programmers out there. It’s coming along nicely.
When I joined the DotNetOpenId team a couple of years ago, the library had already been mostly ported from Janrain’s Boo version, which was itself ported from Janrain’s Python library. Eventually I refactored the entire DotNetOpenId library to not only look and feel more like a native C# library but also be much easier to discover via Intellisense for the end user and made most of the classes internal so that people wouldn’t use the wrong stuff. It was a great exercise for the budding architect in me. But in retrospect, when I look at the implementation of the code I still see quite a few of its original Python roots. Writing unit tests was really tough as the thing wasn’t originally designed with testability in mind, it seemed. I’ve overcome much of that with dozens of test helper methods, but it still feels cumbersome at times.
Starting DotNetOAuth has been a real treat for me, personally. I got to start from the ground up. I read the spec over a few times and tried to get the spirit of it without letting the way it expressed ideas directly imply how I would implement it. I saw a great deal of similar concepts ad requirements with OpenID. In particular the most glaring one was this need to pass messages between two parties both directly and indirectly (which means from one server to another, and via redirects through the browser).
I wanted to capture the concept of messages being passed around in such a way that one could write code that would write up a message, call up a channel and just say "send" in essence and the right thing would happen and the author would not need to know exactly what kind of transport the message needed or anything. When I thought of this, WCF seemed like the obvious solution. It has an extensible message pipe and would be great… or so I thought. And frankly maybe I’m wrong: maybe WCF still could do it. But I found the need for messages to be passed via redirect to be a bit beyond WCF’s designers’ plans and it seemed to fall short. I bet you could do it by writing your own transport binding element, but there were other requirements that WCF didn’t quite meet here and there, and eventually I thought I might as well try writing my own mini-WCF just for passing messages directly and indirectly and see where that took me.
The important goal for me the whole while was that I wanted to write an extensible message passing library that could be used to reconstruct the insides of DotNetOpenId and build up DotNetOAuth, as well as make any future redirection-based protocols very easy and quick to implement.
I’m very happy to report that I succeeded. I have an extensible channel with binding elements including support for message tamper detection, expiring messages and replay detection. The messages can be passed directly or indirectly. The transport itself is very customizable, and most importantly, very testable. Mock transports can be easily injected so that tests can simulate full scenarios of two party communication without actually launching an HTTP server. I went on to write a small test simulation framework so you can write each party’s side of the test separately as two different thread methods, and the framework will allow them to interact as if they were live, yet much faster and easier to step through offline.
So what does this mean for DotNetOpenId? I expect that DotNetOpenId 3.0 will be largely the same on the customer-facing side. But internally (I hope) I’ll have had the time to tear out its innards to use this new messaging framework. It should make it much easier for people who like to read the source code of the open source libraries they consume to understand what’s going on and even write their own tests.
And where is DotNetOAuth? I’ve got a bit of work left to do on it. I’m writing a few more tests and I still have the sample sites to write. It’s probably a few weeks away from going to beta. And I still need to get Microsoft lawyers to sign-off on my ability to publish this work that I’ve done on my spare time since I work at Microsoft and they like to know what their employees are giving away for free. There’s a lot more work on the source code than what I’ve published up at the Google Code web site. So don’t think the work has stalled. I’m just waiting for sign off before I push up all the code changes I’ve made for public viewing.
Watch here for more news.