Flex, Groovy/Grails, and other neat stuff
I’m pleased to announce the latest version of the Stark Security plugin for Grails has been released. Docs have been updated and release notes are available: http://grails.org/plugin/stark-security.
In short, this release upgrades to Spring Security 2.0.5, and contains a fix for configurable support for session fixation attack prevention.
I recently did a “tech talk” at work — an introduction to Adobe’s Flex and AIR. The presentation is geared to the techie with some UI-building experience but with little or no knowledge of Flex or FlexBuilder.
Although there are some high-level introductory/overview slides up front, the bulk of the presentation is a build-it-from-scratch session that shows how to use FlexBuilder to put together a simple Flex app (the obligatory Twitter client). It also shows how to work with a library project, and then goes on to create an AIR application using a shared component. Towards the end, I’m firing up FlexMonkey to show how to test the Flex app we built and how to generate the scripts and AS3 code needed to integrate those tests in a CI build.
The slides are here. There are not that many, but there are some useful links on the last slide.
The Flex projects built during the presentation are here.
Readers of this blog and people on the grails user list noted some difficulties with UTF encoding with the previous release of the stark security plugin. I’m happy to announce this bug-fix release (version 0.4.2) which takes care of the UTF encoding problem, and also fixes another defect related to moving the User and Role domain classes into packages.
Please give it a whirl and let me know if you have any comments and/or questions!
Docs and release notes are here: http://www.grails.org/Stark+Security+Plugin
This is the second release since my last post — since 0.2.x these are the highlight changes:
Updated docs and release details are available here: http://www.grails.org/Stark+Security+Plugin
I’m pleased to announce the release of version 0.2 of the Stark Security plugin. Not a huge deal, but a few convenience enhancements:
The 0.2.2 bug-fix release solves an issue with custom url mappings not responding to the authorization mappings in controllers. With this fix, any custom mappings in UrlMappings will resolve to the authorization mappings of the eventual controller target.
Documentation (including upgrade instructions, release notes, etc.) is here: http://www.grails.org/Stark+Security+Plugin
As always, comments/questions/suggestions are much appreciated!
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:
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):
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.
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.
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.