My new open source Java OAuth library

Posted on March 19, 2010

I’ve just pushed out a new open source java OAuth library because I couldn’t find one that did what I needed. My key requirement was simplicity. I didn’t like the idea of using the library for HTTP stuff and there is no reason I should. Once I’ve obtained the Access Token all I’m doing with oAuth is signing my requests.

I want to use HttpClient directly and only use the oAuth library to sign the message for various reasons not the least of which being that I already have a HttpClient object setup in my IoC container.

The closest I found was signpost but it wasn’t very IoC friendly or thread-safe which meant every time I wanted to make a call I’d have to create new objects, or at the very least call a bunch of methods to set them up which highlights the third problem, there were no clear objects that I could store for later.

The library I’ve just release is a fork of the signpost code, that’s now thread-safe and should be more IoC friendly. You create your method calls as you would normally, and just before you call HttpClient.execute(HttpMethod) simply call OAuthConsumer.sign(HttpMethod, AccessToken);.

I’ve added a few new objects that handle most of the work. Service, RequestToken and AccessToken are all beans that you pass to a consumer depending on what you want to do. Starting with a Service you call

Service service = new Service();
service.setRequestTokenUrl("http://twitter.com/oauth/request_token");
service.setAccessTokenUrl("http://twitter.com/oauth/access_token");

service.setConsumerKey("b8sA385mBBNqOTD6Omlsw");
service.setSharedSecret("MD4Sve6AdaDasjdvOAsbpAJsA87S8s64e5rE4");

service.setMessageSigner(new PlainTextMessageSigner());
service.setSigningStrategy(new AuthorizationHeaderSigningStrategy());

RequestToken requestToken = oAuthConsumer.getRequestToken(twitter);

You’ll have to send the user off to twitter to check their credentials. When they come back
they’ll be given a verifier set it and trade the request token for an access token

requestToken.setVerifier(verifier):
AccessToken accessToken = oAuthConsumer.getAccessToken(requestToken);

Now you can store the accessToken to use later, when you want to simply setup your http method as you would normally.

HttpUriRequest request...
// do your HttpClient stuff here

oAuthConsumer.sign(request, accessToken);
HttpResponse response = httpClient.execute(request);

There is also code in there for the Jetty HttpClient, but it’s a bit rough and I haven’t used it. Have play with it and let me know what you think.

UPDATE: Forgot to link to it… Dumb. It’s on GitHub here.

Announcing Announce.ly

Posted on March 9, 2010

I Released Announce.ly last night, it’s a side project I put together with some of the code that I built for Sproozi.

What’s it good for?

Announce.ly makes it easy to make announcements through twitter.

People have lots of questions about how to use twitter for their business. Should you create an account in the name of the business and use that to communicate, use some of the tools out there to share access to the account. Or you could create an account as a personality to represent the business, many company CEOs do this.

Either way works and there are lots of companies out there following both models successfully but there is another way.

I want to be myself on twitter, I want to make announcements for the projects I’m involved in and I want the project accounts to retweet me when I use hashtags associated with the projects. I don’t want to have to manage accounts for every project.

For example if I tweet an announcement about Announce.ly – “Announce.ly is live! #announcely” then I want the Announce.ly twitter account to retweet it automatically

And that’s what announce.ly does, check it out now to start your free trial then head on over to the Announce.ly blog where we’ll highlight use cases and feature some of our most interesting users.

Some progress on continuous deployment

Posted on March 2, 2010

As I posted a couple of weeks ago I’m working on working a continuous deployment setup so that I can push changes live quicker and easier for the projects I’m working on.

I’ve installed and configured Hudson, which was a good first step. It’s shown me that my builds are a bit fragile, they’re heavily based on packages that I’ve compiled and installed into my local Maven repository. To solve the problem and to make my build a little more sensible I’m getting Artifactory working.

At this stage I’m just trying to get a very basic system in place so that I have an idea of how long a deployment will take. It’s a little more complicated because I’m using Java and the WARs contain all the libraries. I could just use the defaults and push a deployment directly to the target servers, but that doesn’t work. First wars are big, they can easily weigh in at 20Mb.

There are a couple of things I could do here. Ideally I could unroll all the jar libs and only include the classes I need. That would drastically reduce the size, as a bonus I could probably also have it give me a warning that I’m including an unused jar, even better if I could work out the path to the maven dependency. But there’s the whole problem of resources, the fact that using Springframework means most of the classes aren’t being explicitly called and the fact that since I don’t know anything that does all of this this, I’d have to write it all.

So I’ve written that whole idea off, and added a shorter to-do item to make sure I’m only including jars I need. Instead I’ve gone for a far easier solution: deploy exploded wars, and use rsync so I can push only changes to the server.

The next step is to get trigger a Hudson build with a commit-hook and use a successful Hudson build to trigger a script that does the rsync. Then I’ll have very basic continuous deployments up and running albeit without any automatic roll backs of a failed deployment which ultimately is a must, but it’s a start.