Class.forName in Groovy

March 1, 2010

Class.forName(className) does not work properly in Groovy. If you type Class.forName, the JVM does not use the correct class loader.

The solution is to use this instead:


Preventing caching in Grails

February 15, 2010

Your browser caching pages served from Grails can be quite a nuisance. Defining a preventCache()-method like below, and calling that from your controller method, stops the caching.

private static final String HEADER_PRAGMA = "Pragma";
private static final String HEADER_EXPIRES = "Expires";
private static final String HEADER_CACHE_CONTROL = "Cache-Control";

protected preventCache (response) {
    response.setHeader(HEADER_PRAGMA, "no-cache");
    response.setDateHeader(HEADER_EXPIRES, 1L);
    response.setHeader(HEADER_CACHE_CONTROL, "no-cache");
    response.addHeader(HEADER_CACHE_CONTROL, "no-store");

Groovy XML back and forth

February 8, 2010

Groovy has convenient classes for working with XML. You can use the XmlParser (or XmlSlurper) if you want to parse existing XML into a tree structure. You can use the XmlBuilder, if you want to build XML from scratch. But what if you want to read existing XML, change it, and write it back again? It’s easy. You can use the XmlNodePrinter object for that:

def xmltree = new XmlParser.parseText("<node text='hello'>")
xmltree.@text = 'goodbye'
StringWriter writer = new StringWriter()
new XmlNodePrinter(new PrintWriter(writer)).print(xmltree)

Security leak with grails acegi plugin annotations

January 26, 2010

The Spring Security Plugin offers a very easy way to secure URLs in your grails application. It works with users, roles and url patterns. Each user can be assigned a number of roles. Based on the roles a user has, access to URL patterns is granted or rejected by the Spring Security Plugin.

The documentation for the plugin describes three ways to specify the URL patterns that must be secured: by storing security mappings in the database, by storing them in a text file, or by defining annotations on controllers and actions.

Annotations seem to offer an attractive way to define security. But be warned. On grails 1.1.2 and the grails-acegi-plugin-0.5.2, I found a security leak using annotations. The security leak is caused by the way grails handles extensions on a URL.

Look at the following controller:

class TestController {
    def index = { render text: "this page should be secured" }

If you surf to http://myserver:8080/myapp/test/index, you are presented a login screen, because the index controller is secured with @Secured([‘ROLE_ADMIN’]). This is the intended behaviour of the plugin. However, if I add “.html” to the URL, the whole login screen is bypassed. The content of the controller is shown without ever having to login. This is a major security issue, I would say.

The solution I chose, was to use text-based security. This way, you can prevent the above from happening, BUT YOU STILL HAVE TO BE CAREFUL. Do not forget to follow the instructions HERE, or otherwise you will still have the same problem.

Another way of solving the problem, is to disable content negotiation (which is enabled by default!). In Config.groovy, change

grails.mime.file.extensions = true


grails.mime.file.extensions = false

This is not a solution if you need to use content negotiation of course.