Ola Bildtsen

I’m happy to announce the release of the new Stark Security plugin to the Grails plugins repository. It’s a cleaned-up (and, hopefully, simplified) edition of the alternative Spring Security plugin previously mentioned here. The main focus of this plugin is to provide a simple yet strong security solution, and it’s different from the standard acegi and jsecurity plugins in that it offers:

• Lock-down or ‘pessimistic’ approach. Instead of leaving the web application open and relying on configured rules to lock down certain areas, the Stark Security plugin locks down everything by default. Developers open up access on a controller-method basis as they are coding the controllers.
• Authorization mappings by convention. The determination of which roles can access which URLs is declared by convention in every controller, right next to the eventual URL end-points (controller methods). This makes for very straight-forward implementation and maintenance of the security rules.

Version 0.1 is available by simply running this from within your Grails project:

grails install-plugin stark-security

Documentation is available at the Stark Security Plugin page at the Grails plugins web site.

In my previous post “Production-Grade Acegi Security for Grails“, readers correctly commented that the underlying technology for the plugin was rather outdated. Some of the assertions in that post were based on an early version of the standard Acegi plugin for Grails, and the underlying security library was an outdated acegi version.

To make a long story short, I have since upgraded the plugin to the latest version of SpringSecurity (2.0.4 at the time of writing). The plugin is available here as part of a demo application (just like in the previous post):

Continue Reading »

We recently re-wrote a fairly major Flex application, having an opportunity to start from scratch with lessons learned. The previous implementation used the Cairngorm framework, but not quite in line with its intent — it was purely used to in “data commands” to retrieve data from the server.

After reviewing some of the other MVC frameworks out there (PureMVC mostly), we decided to stick with Cairngorm but to expand its use to the full extent it was intended. In our mind, that meant to have Cairngorm events/commands handle all user gestures (unless they were trivial, component-local gestures like re-sorting a datagrid, etc.). This worked great, and we were pretty happy with the emerging structure of the application except for one thing: we didn’t like the ViewHelper/ViewLocator pieces. It seemed too cumbersome and overly structured for the simple task of having a command communicate with a view. We also didn’t like to control views from commands via the ModelLocator (as also suggested by the Cairngorm docs), as we had tried that in the earlier version and it quickly became a disastrous mess of spaghetti bindings that were incredibly hard to unravel, much less maintain.

Continue Reading »

At work, we recently had an opportunity to rebuild the Flex front end to our web application. Having started from scratch with the initial version of the application a year and a half ago (with little prior Flex experience in our staff), this “greenfield” opportunity gave us a chance to take the lessons learned (and new stuff available in Flex 3) and apply them to the new project. One important change, from an architecture point-of-view, was the introduction of modules and how to make them work with deep-linking.

Continue Reading »

Note: See an update/upgrade to this post (moving to SpringSecurity) here.

The standard Acegi plugin for Grails provides a basic implementation of the Acegi security framework for the Grails web stack.  It does a nice job of setting up a basic filter chain that can be rather cumbersome to establish from scratch.  It comes hard-wired with a simple DAO-based authentication provider, and includes the pieces needed to create a rudimentary security scheme for your Grails application.

But the standard plugin is not very flexible, and does not provide alternate means of authentication (such as LDAP).  It is also cumbersome to configure, and it is difficult to manage authorization mappings.  I also didn’t like the “optimistic” authorization scheme (anything not locked down is publicly available).  This article demonstrates a security plugin implementation for Grails that meets a higher level of security requirements.

Continue Reading »