Monthly Archives: January 2010

Securing a GWT Grails app with Shiro

A recent poster on the Grails user mailing list asked how to secure a GWT application using Shiro. The Shiro Plugin is mostly designed to work with Grails controllers and GSPs, so that’s what the current documentation targets. GWT is a different kettle of fish, so can the Shiro Plugin help here?

As it happens, I needed to handle unauthenticated GWT requests myself recently. Here’s the solution I came up with.

Imagine we have a GWT-RPC request come in to the server, but the session has timed out. First off, is the request protected? That depends on how you have your security filters configured. I currently have this:

class SecurityFilters {
    def filters = {
        gwt(controller: "gwt", action: "index") {
            before = {
                accessControl { true }

Because I’m protecting the “gwt” controller, all GWT-RPC requests require an authenticated (or remembered) user. That means whenever the current user’s session times out, Shiro kicks in and asks for authentication. It does this by redirecting to the login page, but this doesn’t work within the context of a GWT-RPC request. So what can you do?

The Shiro plugin allows you to customise the behaviour when the user requires authentication. Simply implement the following method in your filters class:

class SecurityFilters {
    def onNotAuthenticated(subject, filter) {
        if (filter.request.contentType?.startsWith("text/x-gwt-rpc")) {
            filter.render(text: "", status: 401)
            return false
        else {
            // Not an AJAX request, so continue with the default behaviour.
            return true

If this method is implemented, the plugin calls it whenever authentication is required. In this particular case, I return a status of 401 (Unauthorized) if the request is of type GWT-RPC. Otherwise, I trigger the default behaviour (redirection to the login page) by returning true. In other words, the return value of the method determines whether the default behaviour occurs or not.

Note The return value of onNotAuthenticated() only has an effect in version 1.1-SNAPSHOT and greater of the plugin.

That’s it for the server side. All we need to do now is handle the 401 response on the client. How you exactly do this depends on your approach to GWT requests, but the basic mechanics are the same. I use the action handler mechanism supported by the plugin, along with Google Gin, so I can simply wrap the standard action service with a version that handles 401 responses:

public class SecureActionService implements GwtActionServiceAsync {
    private final GwtActionServiceAsync actionService;

    SecureActionService(final GwtActionServiceAsync actionService) {
        this.actionService = actionService;
    public <T extends Response> void execute(final Action<T> action, final AsyncCallback<T> callback) {
        actionService.execute(action, new AsyncCallback<T>() {
            public void onFailure(Throwable caught) {
                if (caught instanceof StatusCodeException &&
                        ((StatusCodeException) caught).getStatusCode() == 401) {
                    // Authentication/authorisation failure. Assume
                    // authentication at this stage and redirect to
                    // login page.
                    final String loginUrl = GWT.getHostPageBaseURL() + "login";
          , "_self", "");
                else {
            public void onSuccess(T result) {

Now all the client code that has the action service injected gets the custom secure service instead. This particular implementation isn’t ideal because it redirects to the standard login page for a 401, whereas it would probably be better to have a simple login popup that then resends the action on successful authentication. However, the key point is that you need to implement the onFailure() method and check for a StatusCodeException. You can then do whatever you want with a 401 response.

The solution outlined above is fairly basic, particularly as it doesn’t deal with unauthorised (as opposed to unauthenticated) access, but it should provide you with a suitable starting point to implement your own solution. You can also see how powerful the command pattern is combined with the dependency injection provided by Google Gin.

One last thing to mention: all the above is geared towards GWT-RPC. If you prefer to use JSON for the client-server communication, then you’ll need a different approach. I have no experience yet on that side of things, but you should be able to check the HTTP headers in onNotAuthenticated to determine whether a request is from GWT or not. Alternatively, simply check for the JSON content type.

‘in’ the groove

I’m sure most of you are aware of the standard Groovy for loop:

for (i in 0..<10) {

It can also iterate over lists:

for (name in listOfNames) {

For many people, that’s where the story of in ends. But did you know that it can be used in conditions as well? Try this:

assert 5 in 0..<10
assert 5 in 0..5
assert !(5 in 0..<5)
assert 5 in [ 1, 4, 5, 7, 8 ]
assert !(5 in [ 1, 2, 4, 7, 8 ])

So it works for ranges and lists. Of course, it also works for sets. And not just numbers, but all objects (because they implement equals()). So if you have code like so

names.findAll { it.firstName == "Peter" || it.firstName == "Alan" }

you can make it a bit more Groovy by using in:

names.findAll { it.firstName in [ "Peter", "Alan"] }

Wonderful stuff. One last note: beware using it with BigDecimal floating point numbers because it may not work the way you expect:

def numbers = [ 1.0, 2.00, 4.567, 3.123 ]
assert 1.0 in numbers
assert 1.000 in numbers

The second assertion fails because 1.0 != 1.000 according to BigDecimal.equals(). Of course, that may change in a future version of Groovy, so it’s always worth checking out in the Groovy console or shell first.

Have fun with your new friend!

A couple of notes about Groovy syntax

I’ve seen a fair bit of Groovy code and there are a couple of common syntax usages that I think could do with some clarification. First off is use of the def keyword.

As we all know, if you want to declare a variable in Groovy with no or dynamic type, you use def. But there are some subtleties to this seemingly simple rule. If you are completely new to Groovy, then you might interpret that rule to mean that an untyped method signature would look like

private def someMethod(def arg1, def arg2) {

Groovy does in fact accept the above, but it’s more verbose that it needs to be. Method arguments need no type:

private def someMethod(arg1, arg2) {

and if the method has a scope (private, protected, etc), then you don’t need def for the return type:

private someMethod(arg1, arg2) {

However, if there is no explicit scope, the return type is required:

def someMethod(arg1, arg2) {

This behaviour extends to fields and local variables as well. You do not need def if a variable is declared with a scope, the static keyword, or final. So all the following are valid field declarations:

private static final name
protected age
static count
final id
static final PATTERN

I guess some people like to use def to keep the syntax consistent with the typed version, but it just adds clutter to my eyes.

The second usage I want to look at concerns GStrings. Many a time I have seen code like this:

println "${name}"

where name is some variable. Notice that there is no other text in the string, it’s just a single variable in a GString. Why? I think there might be two reasons: habit and as a replacement for toString().

Once you get used to using GStrings, they become a habit. I have even found myself doing the above, even when the variable in question is quite definitely a string already! That just causes confusion for anyone reading the code, so I typically get rid of the quotes and braces as soon as I notice. I recommend you do the same, particularly as it may be you reading the code 6 months down the line.

As a replacement for toString(), the GString syntax has the benefit of brevity. Some words of caution though. First, you may not need it. Take a look at the previous example: println() automatically calls toString() on it’s argument, so there’s no need to do it yourself. Second, if the variable or argument is definitely going to be a string, then the GString syntax just obfuscates the code. Last, but definitely not least, you end up with a GString instance.

Most of the time, GStrings and strings can be used interchangeably. In fact, Groovy goes out of it’s way to make sure this is the case, so you don’t have to worry about it. But if you ever do an instanceof check that compares a GString to a string, you’ll get false as a result. It’s not common, but it can happen. We’ve hit the problem a few times in the Grails code.

Before I finish, a quick note on GStrings. Groovy automatically coerces (or converts) some types to others. One such coercion is from GString to String. However, this automatic coercion can only occur if Groovy knows that the target type is a string. For example, if a method argument or a variable is declared explicitly as String. When you use dynamic types, it’s up to you to handle GStrings and normal strings correctly.

Now you know what’s possible, you can make an informed choice as to the style you use.