Password authentication using Groovy

This week I was at a client site that was about as locked down as any I’ve seen. Personally I find that incredibly short-sighted on the part of the company, but it’s always easier to say no, I suppose.

While it was annoying enough to set up a browser to surf the web, that’s not sufficient to access remote sites programmatically. For example, the client does a daily download of exchange rate data from a central site, which they process and store in a local db. I wanted to demonstrate that using Groovy.

Normally, to use a proxy I set the host and port on the command line. I’ve done that in Java (and Groovy) many times:

groovy -DproxyHost=10.x.x.x -DproxyPort=8080 myscript.groovy

Most of the time, that’s all you need. In this particular case, however, I also needed to submit a username and a password for authentication on the proxy server.

There are several sites that show you how to do that in Java. Here’s one of them, and it shows that you need to extend the java.net.Authenticator class and override the getPasswordAuthentication method. Here’s an example in Java:

import java.net.Authenticator;
import java.net.PasswordAuthentication;

public class MyAuthenticator extends Authenticator {
    @Override
    protected PasswordAuthentication getPasswordAuthentication() {
        return new PasswordAuthentication("username","password".toCharArray());
    }
}

Then, in your program, set the new authenticator as the default.

Authenticator.setDefault(new MyAuthenticator());

and you’re good to go.

Of course, I couldn’t leave it at that. I was teaching a Groovy class anyway, so I wanted to make the solution groovier. Here’s what I ultimately used:

Authenticator.default = {
    new PasswordAuthentication('username','password' as char[])
} as Authenticator

I switched from using the setDefault method to setting a property, and coerced a closure with the required method into the proper class. Since the authentication mechanism only calls the getPasswordAuthentication method, I can use the single closure as the implementation. Normally I use closure coercion for interfaces, and then generally if they only have a single method, but it was too easy in this case to ignore.

Besides, showing the simplicity of the Groovy solution made the demo a teachable moment, which at least tried to make some lemonade out of the paranoid security lemons. My favorite part was how I hard-wired both the username and password directly into the script, in clear text no less. I could have found a way around that, but I was on a guest account anyway and it felt nicely subversive to do so.