Grails 2.1.0 app tomcat 7.0.22 Session empty after redirect

Question

I am just learning grails and have a problem with an app that works fine when I run it in Netbeans but shows strange behavior when deployed to Tomcat 7.0.22 on a Centos 5.4 server. I am using the proxy_ajp to make the app available with apache.

The problem seems to be with the session not being maintained after a redirect so that I lose the login information causing the app to try to login again.

My proxy_ajp settings are

<Location /PreyerBooks >
   ProxyPass ajp://localhost:8011/PreyerBooks    
   ProxyPassReverse ajp://localhost:8011/PreyerBooks
</Location>

the app is deploying without errors and the connectivity to the database and LDAP is working. I tested this by logging in the authenticate method as follows

UserController - authentication function

 def authenticate = {
    def password=passhash(params.password)
    log.info " login attempt ${params.login} - ${params.password} - ${password}"
    def match = User.findAll(
      directory: "user",
      filter: "(&(uid=${params.login})(userpassword=${password}))"
    )
    log.info " match ${match}"
    if (match) {
      def user = Employee.findByLogin(params.login)
      log.info " user ${user} - ${user?.role}"
      if(user){
        session.user = user
        log.info "success"
        flash.message = "Hello ${user.firstname}!"
        redirect(controller:"Book", action:"index")      
      }else{
        log.error "failed login attempt mismatch to ldap ${params.login}"
        flash.message = "Sorry, ${params.login}. Please try again."
        redirect(action:"login")
      }
    }else{
      log.error "failed login attempt ${params.login} - ${params.password}"
      flash.message = "Sorry, ${params.login}. Please try again."
      redirect(action:"login")
    }
  }

BookController - auth function (checks if logged in)

  def beforeInterceptor = [action:this.&auth, except:[]]

  def auth() {
    log.info "BookController:auth() ${session}"

    if(!session.user) {
      redirect(controller:"User", action:"login")
      return false
    }
    log.info "BookController:auth() working"
    return true
  }

The log shows

 INFO  books.UserController  -  login attempt username - password - passwordhash
 INFO  books.UserController  -  match [de.preyer.books.User@d4a1cc]
 INFO  books.UserController  -  user username - admin
 INFO  books.UserController  - success
 INFO  books.BookController  -  BookController:auth() Session Content:

The session.user variable has vanished. I checked the passwordhash and it correctly matches against the LDAP server (hence the object reference in match). This user is correctly found in the database where it gains its role.

I cannot access the app directly avoiding the apache ajp as the port is blocked in the firewall and I cannot open it. Thus I cannot test if the problem is in the ajp or tomcat in general

I have tried searching for the criteria specified as the title but find nothing relevant.

a) browser cookies are enabled and working, I tried Safari, Firefox and Chrome without success. I do not think this is a browser issue as the same browsers work with the app in NetBeans (using jetty I think)

b) I have set grails.serverURL = "http://servername/PreyerBooks" to the fully qualified domain

If I turn of the auth the app works.

I must be doing something wrong or have missed a step in the deployment.

Now I know I can include a plugin using Spring Core but this is overkill for my application and adds a further level of complexity to the debugging. I wish to get the current implementation working before moving on. The logic is copied from the Grails 2.1.0 documentation so it should work.

I read in httpSession that things must be serializable but if the example in the documentation does not work why does the app work when I run it in NetBeans?

I am at a loss. Any help would be much appreciated.

Answer 1

Use the spring-security-core plugin (or Shiro, or any established, proven security implementation). It's not complex, and rolling your own security is a quick path to getting hacked.