Comments on: Securing Grails Plugin Artifacts with Filters

By: Matt Passell

Matt Passell — Fri, 04 Dec 2009 18:29:25 +0000

Hi (other) Matt,

I’m not sure how relevant this is after Burt’s very helpful suggestion, but I noticed that your second code snippet is exactly the same as the first. You meant to include some code from SecurityConfig.groovy there, right?

–Matt

By: Bruce Richardson

Bruce Richardson — Sun, 29 Nov 2009 09:54:10 +0000

For me, this demonstrates the dangers and problems of using annotations in this way. Now you have two ways to indicate security settings and you have to audit them both. If you’d done with the external configuration option, you’d have the one way and the one set of problems.

There are now a huge number of frameworks offering the use of annotations for configuration (Hibernate, Spring, JAX-WS etc.) Use all their annotations and your domain objects will be decorated like the outside of a Minnesotan house at Christmas (visit Minnesota any December to find out just how garish that is). Not only does it obscure the code rather than enhancing it, it means that code is changed much more frequently than it should.

Annotations should be intrinsically meaningful to the objects they adorn, so that any code you write can make intelligent use of them, or they should be meaningful in contexts so widely understood that their purpose will not be lost . This often means that the only useful annotations are those meaningful to the Java compiler, but other annotations can be valid *if* the annotated object will only be used in a context where those annotations are universally understood. Security for Grails controllers is a good candidate for the second, but since the use of annotations for security isn’t part of the Grails core, which would encourage every security-plugin developer to adopt a single standard, they fail.

The whole Java world and their pets seem to be gleefully ignoring this and adopting annotation-based configuration like crazy. It’s wrong, it will bite them and maybe they’ll learn.

By: Matt

Matt — Wed, 11 Nov 2009 02:04:58 +0000

OK, so why have I never been able to find this before?!?!? This is exactly the behavior that I have wanted out of the plugin, but somehow I have never been able to track it down. Definitely a far superior approach. Thanks!

By: Burt Beckwith

Burt Beckwith — Tue, 10 Nov 2009 23:44:25 +0000

Check out the ‘controllerAnnotationStaticRules’ discussion in the annotation section of http://grails.org/AcegiSecurity+Plugin+-+Securing+URLs

This is used to secure URL patterns that can’t be annotated, i.e. static resources (JavaScript, CSS, etc.) and controllers that you can’t edit for whatever reason:

controllerAnnotationStaticRules = [
'/blurb/**': ['ROLE_ADMIN'],
‘/setting/**’: ['ROLE_ADMIN']
]

This has the advantage over the filter approach of being fully integrated into the plugin and Spring Security, in that when navigating to a secured controller the requested URL will be remembered, and after a successful login you’ll be redirected to that URL.