Jan is correct – bcrypt by design doesn’t generate the same hash for each input string. But there’s a way to check that a hashed password is valid, and it’s incorporated into the associated password encoder. So add a dependency injection for the passwordEncoder
bean in your controller (def passwordEncoder
) and change the lookup to
def handleLogin = {
if (springSecurityService.isLoggedIn()) {
render(view: "../homepage")
return
}
def user = Registration.findByEmail(params.email)
if (user && !passwordEncoder.isPasswordValid(user.password, params.password, null)) {
user = null
}
if (!user) {
flash.message = "User not found for email: ${params.email}"
render(view: "../index")
return
}
session.user = user
render(view: "../homepage")
}
Note that you don’t encode the password for the isPasswordValid
call – pass in the cleartext submitted password.
Also – completely unrelated – it’s a bad idea to store the user in the session. The auth principal is readily available and stores the user id to make it easy to reload the user as needed (e.g. User.get(springSecurityService.principal.id)
. Storing disconnected potentially large Hibernate objects works great in dev mode when you’re the only user of your server, but can be a significant waste of memory and forces you to work around the objects being disconnected (e.g. having to use merge
, etc.).