Peter Ledbrook

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;

    @Inject
    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";
                    Window.open(loginUrl, "_self", "");
                }
                else {
                    callback.onFailure(caught);
                }
            }

            public void onSuccess(T result) {
                callback.onSuccess(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.

London GGUG in the new year

After a successful Groovy & Grails eXchange run by SkillsMatter last week, it seems that there is plenty of interest in keeping the London GGUG going on a regular basis. Several ideas were floated then, so I thought I’d bring them up here and elicit feedback:

1. Two or three standard talks of 30-45mins each about any subject. Topics I would like to see covered include (in no particular order):
   • Gaelyk
   • Griffon
   • Real life Grails on Google App Engine
   • Real life Grails on Cloud Foundry
   • Grails deployment and data migration
   • GPars and/or static Groovy
   • Writing AST transformations
2. 6 * 10-15min slots on any topic, first come, first served
3. Plugin-fest – anyone can get up and present for 5-15 mins on their favourite plugins (no agenda)
4. Crowd-programming on an app, plugin, Grails issues, or anything else

If anyone has other ideas on session types or topics, then please let me know. I’m hoping that I can organise one with SkillsMatter sometime in mid- to late-January, so place your vote on what type of session you’d like! I’m currently thinking of a session with 5 or 6 10-15 min talks on what people are using Grails for, with plenty of time for questions.

I hope to see you in the new year!

A rant about QWERTY

OK, so it seems that it’s no longer fashionable to knock the QWERTY keyboard layout (or QWERTZ in Germany, I gather). A couple of times I’ve moaned about the layout, people have said its got a worse reputation than it deserves. Well, maybe.

I did have a quick look at Wikipedia to find out some information, and that directed me to a one page QWERTY history. If that page is accurate, then it may not have been designed to slow down typists, but the aim of reducing the number of jams in a typewriter at the end of the 19th century is hardly geared towards efficient typing on computer keyboards. It’s not like we have to worry about jams these days, although crumbs, coffee, and other such evils are a different matter.

Anyway, it’s not really QWERTY per se that bugs me. Yes, I think the Dvorak layout puts less strain on my fingers’ tendons. But I can nonetheless type fairly fast on a QWERTY keyboard (it’s only taken 15 years of software development to get there!). No, my main gripe is with using QWERTY on touch screens.

One of my most memorable experiences with this was when I was trying to buy a train ticket from a new electronic ticket machine. There were many design issues with this machine, but I want to focus on the touchscreen keyboard. This is presented to the customer when he or she needs to go anywhere not on the quick links screen. Unfortunately my parents live in a not-particularly-large village, hence I had to type in the name of the station. That’s when I suddenly realised I had no idea where the keys were on the QWERTY keyboard!

This may seem strange at first glance, because I use a keyboard almost every day of my life (how sad is that?), but once you take into account the fact that I touch-type, things start to make sense. I don’t visually map the letters to the keyboard – my fingers in effect just take on a mind of their own. As soon as I was faced with the QWERTY layout and had to visually locate the letters, I struggled because it has no logic. I got to the stage where I was putting my hands on the screen as if I were typing!

What about all those people that don’t have experience with QWERTY? I know that techies may find this hard to believe, but not everyone has a lot of experience with computers and their keyboards, whereas almost everyone knows the alphabet. So why not display the keys in alphabetical order? I really think that no one actually bothered to field test the on-screen keyboard layout and simply went with QWERTY because “everyone knows it”.

Every on-screen keyboard layout I have seen goes with QWERTY, but I’m convinced this is completely wrong-headed for any situation that doesn’t involve touch-typing. In particular, any application that can’t handle fast typing (I’m looking at you, ticket machine) has no call to use QWERTY. Nor does any application that is used by people of all ages and backgrounds. Unfortunately, I can’t help but feel that this travesty will continue until even our grannies eventually learn where the QWERTY keys are.