I think this is a good question.
I started using Grails about 5 months ago, and one of the first things I did was to install Spring Security and Spring Security UI. I initially used the RegisterController
provided by the plugin, however I ended up rewriting most of it.
The UI RegisterController
contains a lot a business logic - I prefer to keep my controllers as dumb as possible, so I created a RegistrationService
and moved the RegisterController
code I needed there.
Another gotcha was the RegisterController
's use of the grails command object pattern. I ran into problems when I deployed my app to CloudFoundry and couldn't figure out why. I later read that other people had experienced the same issue. Simple workaround, but it left me scratching my head for a while...
Hope this helps.
EDIT:
So, on to your actual question. I guess the approach I took when I needed to add fields and otherwise customise the way the plugin worked was to just write my own implementation.
You can override the default Spring Security UI User
, Role
and UserRole
classes by adding this to Config.groovy
:
grails.plugins.springsecurity.userLookup.userDomainClassName = 'com.myapp.MyUser'
grails.plugins.springsecurity.userLookup.authorityJoinClassName = 'com.myapp.MyUserRole'
grails.plugins.springsecurity.authority.className = 'com.myapp.MyRole'
If you need additional fields, just add them to your User
domain class, you'll also need to add validation logic to the RegisterController
's Command
s to deal with these additional fields.
As for pulling your Command
s out as top level classes, I just keep mine in the same package as the controller. One thing to note is that since they're no longer inside your controller, they will need to have a @grails.validation.Validateable
annotation added to them otherwise they won't have the various validation methods available to them at runtime.