locrian code

Using Jetty form-based authentication with Dropwizard

Mon, 15 Aug 2016 17:46:53 +0100

Dropwizard is a rather nice Java REST framework. Although mainly designed for web services, it can also be used for MVC-style web applications, with dropwizard-views which supports both FreeMarker and Mustache templates on the front end.

What’s missing out of the box is form-based authentication. The embedded Jetty web server does contain this functionality — but there are a number of steps involved in getting it wired up.

First, create /login and /logout pages

Let’s create a simple Jersey resource for each page. We’ll also create a /login/error page to handle failed logins.

@Path("/login")
public class LoginResource {

	@GET
	public View login() {
		return new LoginView();
	}
	
	@GET @Path("error")
	public String error() {
		return "Error logging in.";
	}
}

@Path("/logout")
public class LogoutResource {

	@GET
	public String logout(@Context HttpServletRequest req) {
		
		req.getSession().invalidate();
		return "You have been logged out.";
	}
}

The login page needs to post to the special /j_security_check endpoint, so your login view should look something like this:

<html>
<head><title>Log in</title></head>
<body>

<form method='POST' action='/j_security_check'>
  <input type='text' name='j_username'/>
  <input type='password' name='j_password'/>
  <input type='submit' value='Login'/>
</form>

</body>
</html>

Automatically redirect 403 Forbidden responses to the login page

HTTP 403 responses are represented by the JAX-RS class ForbiddenException.

To handle these, we need an ExceptionMapper that will store the target URI in session and then redirect the user to the login page. Once they have logged in, Jetty will retrieve the URI and forward the user to their original destination.

public class ForbiddenExceptionMapper implements ExceptionMapper<ForbiddenException> {
	
	private UriInfo ui;
	private HttpServletRequest req;
	
	public ForbiddenExceptionMapper(@Context UriInfo ui, @Context HttpServletRequest req) {
		this.ui = ui;
		this.req = req;
	}

	@Override public Response toResponse(ForbiddenException e) {

		String location = ui.getPath();
		
		if (location != null) {
			req.getSession().setAttribute(FormAuthenticator.__J_URI, location);
		}
		return Response.temporaryRedirect(URI.create("/login")).build();
	}
	
}

Create a new server factory

To work, the auth service needs to be initialised at the correct point in Jetty’s lifecycle; after the server has been created but before the app servlet is added. We’ll need a custom ServerFactory so we can hook into Jetty at the right time.

@JsonTypeName("jettyauthserver")
public class JettyAuthServerFactory extends DefaultServerFactory {

    @Override
    protected Handler createAppServlet(Server server, JerseyEnvironment jersey,
        ObjectMapper objectMapper, Validator validator, MutableServletContextHandler handler,
        Servlet jerseyContainer, MetricRegistry metricRegistry) {

        setupJettyAuth(handler);

        return super.createAppServlet(server, jersey, objectMapper, validator, handler,
            jerseyContainer, metricRegistry);
    }

    private static void setupJettyAuth(MutableServletContextHandler context) {
    	
    	context.setSessionHandler(new SessionHandler());
    	
    	Constraint constraint = new Constraint();
    	constraint.setName(Constraint.__FORM_AUTH);
    	constraint.setRoles(new String[]{"user","admin","moderator"});
    	constraint.setAuthenticate(true);

    	ConstraintSecurityHandler securityHandler = new ConstraintSecurityHandler();

    	HashLoginService loginService = new HashLoginService();
    	loginService.putUser("defaultuser", new Password("defaultpass"), new String[] {"admin"});
    	
    	FormAuthenticator authenticator = new FormAuthenticator("/login", "/login/error", false);
    	securityHandler.setAuthenticator(authenticator);

    	context.setSecurityHandler(securityHandler);
    }

}

Note: this example authenticates using a fixed, in-memory list of roles and user names. For a real application, you’ll want to actually use a database.

To do this, replace the HashLoginService with a JDBCLoginService (or your own login service implementation).

Register the server factory

Create a text file called io.dropwizard.server.ServerFactory and save it in src/main/java/resources/META-INF/services/

The file needs to contain the fully qualified name of the new server factory. For example:

com.example.JettyAuthServerFactory

Finally, register the server name in your application YAML config:

server:
  type:
    jettyauthserver

Application setup

To hook everything up, these lines need to go in the run() method of your Dropwizard application.

// Enable the Jersey security annotations on resources 
environment.jersey().getResourceConfig().register(RolesAllowedDynamicFeature.class);

// Register custom exception mapper to redirect 403 errors to the login page
environment.jersey().register(ForbiddenExceptionMapper.class);

// Register the Login and Logout resources
environment.jersey().register(new LoginResource());
environment.jersey().register(new LogoutResource());

Try it out

With all the pieces in place, you can now use Jersey’s declarative security annotations to protect resources:

@Path("/topsecret")
@RolesAllowed("admin")
public class TopSecretResource {

    /* ... */

}

Contact

Sun, 14 Aug 2016 22:15:33 +0100

Get in touch by sending me an email.

About

Sun, 14 Aug 2016 17:47:21 +0100

New Beginnings

Sun, 14 Aug 2016 13:39:40 +0100

So I decided it was finally time to resurrect this blog and bring it into the 21st century. It’s now powered by Hugo, a static site generator written in Go.

I promise there will be a few more posts soon!

Closure Exposure

Tue, 21 Dec 2010 00:00:00 +0000

These days people are becoming more aware that you can write real object oriented code in Javascript. Even though the language doesn’t support classes with private members directly, you can achieve the same thing quite easily using closures.

function MyClass() {
    // Private members
    var internalCounter = 0;
    var somePrivateFunction = function(input) {
        return input + " foo!";
    };

    // Public members
    this.getCounter = function() {
        return internalCounter;
    };
    this.increment = function() {
        internalCounter++;
    };
}

Here, the first two members are effectively private, as they can only be accessed from functions declared within MyClass.

This is all well and good, and makes me feel much better when I have to write Javascript, but if you’re a serious Javascript developer you’ll want to unit test your code as you go along. How are you going to test those pesky private variables and functions?

Dude, let me in!

The problem is, you can’t break into a closure because it’s enforced by the language. You can try as hard as you like, but there’s no way you’re getting access to somePrivateFunction() without modifying the code of MyClass. This is a good thing - it means the private functions are truly encapsulated. But it does make testing a bit difficult.

One trick I like is to add the following line to the end of the class constructor.

this.debug = function(code) { return eval(code); };

Because of the way the eval command works, this now means that any of the private members can be extracted from within the class. For example, we can now write a unit test for somePrivateFunction. (This is a QUnit test, which is the test framework jQuery uses).

test("somePrivateFunction", function() {
    var my = new MyClass();

    // extract the private function from the closure
    var somePrivateFunction = my.debug("somePrivateFunction");

    // call the function
    equals(somePrivateFunction("hello"), "hello foo!");
});

We have slightly polluted the original class with this extra line. If it worries you, the ‘debug’ lines can easily be stripped out before the code goes into production.

Static classes and unit testing

Fri, 25 Jun 2010 00:00:00 +0000

If you unit test your code (and I hope you do), you’ll quickly discover that you need to mock out parts of the system. This is much easier if you design with testability in mind from the start of the project. In particular, as you’ll see, you need to be very careful about where you use static classes.

Generally when people first learn about object oriented programming it takes a while for the concepts to sink in. If you’re used to procedural languages the world of objects can seem strange and full of unnecessary bloat: why are my functions called ‘methods’, and why do I have to put them all in this thing called a ‘class’? Beginners end up creating classes full of static methods, mimicking the style of procedural programs. Unfortunately a lot of experienced programmers do the same thing. A static method can look like a deceptively simple solution but often there are good reasons to create a fully fledged class instead.

When it’s OK

But first of all, let’s look at the situations when it really is OK to use a static method. To do that I’m going to borrow a term from functional programming called ‘referential transparency’. For example, here’s a method which is referentially transparent:

boolean emailAddressIsValid(String email) { ... }

It carries out some tests on the email address and returns a boolean value. Perhaps it checks that it contains the @ and at least one dot in the domain section. The important part is that it doesn’t do anything else - it doesn’t interact with the screen or the keyboard, call a database, or modify any values elsewhere in the program. All these things are ‘side effects’. Pure functional programmers believe that functions should never, ever, cause side effects, but if you followed this at work your programs wouldn’t ever do anything and your boss might not be happy.

You can put all your methods into two categories: ones that cause side effects, and ones that don’t. If a method is side-effect free, all its dependencies (the methods it calls) have to be side-effect free as well. You’ll never need to mock these methods, so they can be made static. To look at it another way, consider that a method like this doesn’t change the state of the program or it’s environment. As object-oriented classes are essentially a representation of state, there’s a sense in which this method exists independently, and doesn’t need to be associated with an instance of an class.

When it’s not

All the other methods cause side effects. If a method calls a database, or sends an email, it’s pretty clear that you’ll need to mock it at some point down the line. Even methods that print output to the screen or read keyboard input should be mockable, if you ever want to test their behaviour.

The object-oriented solution to this is polymorphism. This means creating a base class, or preferably an interface for more flexibility, and coding against the interface rather than the implementation. This is the open/closed principle in action. You’ll still need to create the concrete class at some point, and dependency injection and inversion of control are useful techniques here. But if the class was static, none of this would be possible and you would lose all the benefits of OOP.