Spring Security Grails plugin 1.2.4 and transparent password encoding in the User domain object

Just spent some significant time today integrating Spring Security Grails plugin 1.2.4. It should have been a quick integration but I got stuck on some new functionality that has been added to the generated User domain object that this plugin generates when using the quick start script. You should now set the password on this domain object using the cleartext string. Look at the User domain object (you may have it named something else, but it's the domain object that represents the user). This domain class is now handling the encoding of the password transparently. I copied some code from another Grails app that was doing the encoding of the password explicitly. You should no longer do this--it will cause problems when attempting to authenticate. Basically I was doubly encoding the password, the plugin definitely does not like that. Here's what the plugin generates for a user domain object in 1.2.4:

 1 class User {
 2 
 3     transient springSecurityService
 4 
 5     String username
 6     String password
 7     boolean enabled
 8     boolean accountExpired
 9     boolean accountLocked
10     boolean passwordExpired
11 
12     static constraints = {
13         username blank: false, unique: true
14         password blank: false
15     }
16 
17     static mapping = {
18         password column: '`password`'
19     }
20 
21     Set<Role> getAuthorities() {
22         UserRole.findAllByUser(this).collect { it.role } as Set
23     }
24 
25     def beforeInsert() {
26         encodePassword()
27     }
28 
29     def beforeUpdate() {
30         if (isDirty('password')) {
31             encodePassword()
32         }
33     }
34 
35     protected void encodePassword() {
36         password = springSecurityService.encodePassword(password)
37     }
38 }

Notice that the domain object now has a springSecurityService injected into it. There's also some GORM callbacks that will be called before the state of the domain object is saved and updated in the database. This is where the encoding now occurs--you should not be doing the encoding explicitly yourself.

Lesson learned!