Archive for the Category 'grails'

One more approach for diagnosing spring-security-core login errors

Thursday, January 30th, 2014

I wrote up a few techniques to help determine what is happening when you are unable to authenticate with use the Grails spring-security-core plugin here and since then I’ve had to use them myself a couple of times. I have everything configured to easily debug the issues and often that ends up being the best approach, but not everyone is comfortable with a debugger, or not excited about the prospect of configuring their IDE with JAR sources and the other steps needed to properly debug. This and this Stack Overflow question prompted me to document another approach.

This one is a rather dangerous and should be removed as soon as the issue is resolved because it prints cleartext passwords to the console, which is a huge security risk.

There are a handful of places where the cleartext password is available, but I think the most convenient is in the additionalAuthenticationChecks method of DaoAuthenticationProvider. The arguments to the method are the UserDetails instance, which will have the hashed password from the database, and the UsernamePasswordAuthenticationToken which will have the cleartext password.

To access this, create a subclass of DaoAuthenticationProvider:

package deletethisasap

import org.springframework.security.authentication.UsernamePasswordAuthenticationToken as UPAT
import org.springframework.security.authentication.dao.DaoAuthenticationProvider
import org.springframework.security.core.Authentication
import org.springframework.security.core.AuthenticationException
import org.springframework.security.core.userdetails.UserDetails

class MyDaoAuthenticationProvider extends DaoAuthenticationProvider {

  protected void additionalAuthenticationChecks(UserDetails ud, UPAT auth) throws AuthenticationException {
    String hashedPassword = passwordEncoder.encodePassword(
         auth.credentials, null)
    boolean ok = passwordEncoder.isPasswordValid(
         ud.password, auth.credentials, null)
    println "Cleartext: '$auth.credentials' from DB: '$ud.password' hashed '$hashedPassword' Valid: $ok"
    super.additionalAuthenticationChecks ud, auth
  }
}

and register it with the same bean name in grails-app/conf/spring/resources.groovy:

import deletethisasap.MyDaoAuthenticationProvider

beans = {
  daoAuthenticationProvider(MyDaoAuthenticationProvider) {
    userDetailsService = ref('userDetailsService')
    passwordEncoder = ref('passwordEncoder')
    userCache = ref('userCache')
    saltSource = ref('saltSource')
    preAuthenticationChecks = ref('preAuthenticationChecks')
    postAuthenticationChecks = ref('postAuthenticationChecks')
    authoritiesMapper = ref('authoritiesMapper')
    hideUserNotFoundExceptions = true
  }
}

It prints the hashed password and the cleartext password, and the cleartext password hashed for comparison. This won’t necessarily be the same as the value from the database, for example when using bcrypt, but the encoder has an isPasswordValid method to verify that they’re equivalent, so that is also printed.

This code assumes that you’re using standard form-based authentication (i.e. DaoAuthenticationProvider) and that you’re not using a salt. If you are using salted passwords, dependency-inject the saltSource bean and use it in the encodePassword and isPasswordValid methods.

Automatically converting password hashes in Grails spring-security-core

Friday, December 20th, 2013

I was looking at this Stack Overflow question about converting password hashes and realized that it’s possible and rather convenient when using the spring-security-core plugin to automate the process.

To start, we’ll need a PasswordEncoder that can work with both algorithms. Here I’m assuming that you’ll be converting from SHA-256 (optionally with a salt) to bcrypt, but the general approach is mostly independent of the algorithms. Sha256ToBCryptPasswordEncoder will always hash new passwords using bcrypt, but can detect the difference between hashes from SHA-256 and bcrypt in isPasswordValid:

package com.burtbeckwith.grails.security;

import grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder;

import org.springframework.security.authentication.encoding.MessageDigestPasswordEncoder;

public class Sha256ToBCryptPasswordEncoder
       implements org.springframework.security.authentication.encoding.PasswordEncoder {

   protected MessageDigestPasswordEncoder sha256PasswordEncoder;
   protected BCryptPasswordEncoder bcryptPasswordEncoder;

   public String encodePassword(String rawPass, Object salt) {
      return bcryptPasswordEncoder.encodePassword(rawPass, null);
   }

   public boolean isPasswordValid(String encPass,
            String rawPass, Object salt) {
      if (encPass.startsWith("$2a$10$") && encPass.length() == 60) {
         // already bcrypt
         return bcryptPasswordEncoder.isPasswordValid(
                    encPass, rawPass, null);
      }

      if (encPass.length() == 64) {
         return sha256PasswordEncoder.isPasswordValid(
                    encPass, rawPass, salt);
      }

      // TODO
      return false;
   }

   /**
    * Dependency injection for the bcrypt password encoder
    * @param encoder the encoder
    */
   public void setBcryptPasswordEncoder(BCryptPasswordEncoder encoder) {
      bcryptPasswordEncoder = encoder;
   }

   /**
    * Dependency injection for the SHA-256 password encoder
    * @param encoder the encoder
    */
   public void setSha256PasswordEncoder(
           MessageDigestPasswordEncoder encoder) {
      sha256PasswordEncoder = encoder;
   }
}

This needs dependency injections for properly configured SHA-256 and bcrypt encoders, and we’ll see that in a bit.

Sha256ToBCryptPasswordEncoder cannot make any changes as only password information is available, so we’ll subclass DaoAuthenticationProvider and do this work in additionalAuthenticationChecks:

package com.burtbeckwith.grails.security

import grails.plugin.springsecurity.SpringSecurityUtils
import grails.plugin.springsecurity.userdetails.GrailsUser

import org.springframework.security.authentication.UsernamePasswordAuthenticationToken
import org.springframework.security.authentication.dao.DaoAuthenticationProvider
import org.springframework.security.core.AuthenticationException
import org.springframework.security.core.userdetails.UserDetails

class PasswordFixingDaoAuthenticationProvider
extends DaoAuthenticationProvider {

   def grailsApplication

   protected void additionalAuthenticationChecks(
         UserDetails userDetails,
         UsernamePasswordAuthenticationToken authentication)
            throws AuthenticationException {
      super.additionalAuthenticationChecks userDetails, authentication

      // if we got this far the password was ok

      String oldHashedPassword = userDetails.getPassword()
      if (oldHashedPassword.startsWith('$2a$10$') &&
            oldHashedPassword.length() == 60) {
         // already bcrypt
         return
      }

      if (oldHashedPassword.length() != 64) {
         // TODO
         return
      }

      String bcryptPassword = getPasswordEncoder().encodePassword(
               authentication.credentials, null) 

      // use HQL to update the password in the database directly

      def conf = SpringSecurityUtils.securityConfig
      String userClassName = conf.userLookup.userDomainClassName
      Class<?> User = grailsApplication.getDomainClass(userClassName).clazz

      def args = [p: bcryptPassword]
      String hql = 'update ' + User.name + ' u set u.password=:p where '
      if (userDetails instanceof GrailsUser) {
         hql += 'u.id=:id'
         args.id = userDetails.id
      }
      else {
         hql += 'u.' + conf.userLookup.usernamePropertyName + '=:un'
         args.un = userDetails.username
      }

      User.withNewSession {
         User.withTransaction {
            User.executeUpdate hql, args
         }
      }
   }
}

Calling super.additionalAuthenticationChecks() will ensure that a password was provided and it will be verified using either SHA-256 or bcrypt by Sha256ToBCryptPasswordEncoder, so if there is no exception thrown it’s safe to update the password. Note that the update code is generic and can be made more compact by hard-coding your class and property names.

We register Sha256ToBCryptPasswordEncoder as the passwordEncoder bean, and create bcryptPasswordEncoder and sha256PasswordEncoder beans, configured with the SHA-256 settings that were being used, and the bcrypt settings that will be used (configure those in Config.groovy as described in the docs). Also configure the bean override of daoAuthenticationProvider to be a PasswordFixingDaoAuthenticationProvider with the same configuration as is done in SpringSecurityCoreGrailsPlugin.groovy with the addition of the grailsApplication reference:

import grails.plugin.springsecurity.SpringSecurityUtils
import grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder

import org.springframework.security.authentication.encoding.MessageDigestPasswordEncoder

import com.burtbeckwith.grails.security.PasswordFixingDaoAuthenticationProvider
import com.burtbeckwith.grails.security.Sha256ToBCryptPasswordEncoder

beans = {

   def conf = SpringSecurityUtils.securityConfig

   bcryptPasswordEncoder(BCryptPasswordEncoder, conf.password.bcrypt.logrounds) // 10

   sha256PasswordEncoder(MessageDigestPasswordEncoder, conf.password.algorithm) {
      encodeHashAsBase64 = conf.password.encodeHashAsBase64 // false
      iterations = conf.password.hash.iterations // 10000
   }

   passwordEncoder(Sha256ToBCryptPasswordEncoder) {
      bcryptPasswordEncoder = ref('bcryptPasswordEncoder')
      sha256PasswordEncoder = ref('sha256PasswordEncoder')
   }

   daoAuthenticationProvider(PasswordFixingDaoAuthenticationProvider) {
      userDetailsService = ref('userDetailsService')
      passwordEncoder = ref('passwordEncoder')
      userCache = ref('userCache')
      saltSource = ref('saltSource')
      preAuthenticationChecks = ref('preAuthenticationChecks')
      postAuthenticationChecks = ref('postAuthenticationChecks')
      authoritiesMapper = ref('authoritiesMapper')
      hideUserNotFoundExceptions = conf.dao.hideUserNotFoundExceptions // true
      grailsApplication = ref('grailsApplication')
   }
}

With this configuration, new users’ passwords will be hashed with bcrypt, and valid existing users’ passwords will be converted to bcrypt using the plaintext passwords used during login. Once your users are converted, back out these changes and convert to the standard bcrypt approach. This would involve deleting the grails.plugin.springsecurity.password.algorithm attribute and all salt configuration since bcrypt doesn’t support a salt, deleting Sha256ToBCryptPasswordEncoder and PasswordFixingDaoAuthenticationProvider, and removing the bcryptPasswordEncoder and sha256PasswordEncoder bean definitions and passwordEncoder and daoAuthenticationProvider overrides from resources.groovy since the beans configured by the plugin using Config.groovy settings will be sufficient. Also if you had added salt to the User class encodePassword method, e.g.

protected void encodePassword() {
   password = springSecurityService.encodePassword(password, username)
}

convert it back to the default without a salt:

protected void encodePassword() {
   password = springSecurityService.encodePassword(password)
}

Some approaches for diagnosing spring-security-core login errors

Wednesday, December 11th, 2013

If you use the Grails spring-security-core plugin and you’re unable to authenticate, it can be hard to know where to start looking for the cause. Often it’s due to confusion from older blog posts that tell you to explicitly hash the password when creating a user, e.g.

def user = new User(username: 'me', enabled: true,
     password: springSecurityService.encodePassword('password')).save()

But the generated User domain class auto-hashes your password for you, so you would just do this (I omitted setting enabled since in 2.0 it defaults to true):

def user = new User(username: 'me', password: 'password').save()

If that isn’t the problem, Spring Security logs a lot at the debug level, so enable that in the log4j block in Config.groovy:

log4j = {
   ...
   debug 'org.springframework.security'
}

With any luck there will be a useful signal in the noise and it’ll point you in the right direction.

If that doesn’t do it, you can configure a debugger and set a breakpoint in org.springframework.security.authentication.ProviderManager in the authenticate method. That’s where each registered AuthenticationProvider gets a chance to attempt an authentication if it supports the current Authentication.

Not everyone likes to use a debugger though. Another option is to register an event listener and look at the failure events. This is described in the plugin docs here. Here’s a simple configuration that will print information to the console for all failure events:

grails.plugin.springsecurity.useSecurityEventListener = true
grails.plugin.springsecurity.onAbstractAuthenticationFailureEvent = { e, appCtx ->
   println "\nERROR auth failed for user $e.authentication.name: $e.exception.message\n"
}

Using MongoDB With Version 2.x of the Grails Spring Security Core Plugin

Sunday, December 01st, 2013

With a few customization steps it’s easy to use MongoDB to store user and role information for the spring-security-core plugin instead of using Hibernate, and after seeing this Stack Overflow question I thought I’d write up some notes on how to do this with the current plugins. Note that much of this is based on this blog post.

I created a demo application using Grails 2.3.3; it’s available on GitHub. The general steps were:

  • $ grails create-app mongoSpringSecurity
  • add the plugins to BuildConfig.groovy
  • $ grails s2-quickstart auth User Role
  • update DataSource.groovy to use MongoDB
  • create a custom UserDetailsService and register it in resources.groovy
  • create a test role and a user in BootStrap.groovy
  • customize the domain classes to use MongoDB
  • add tags to index.gsp to add a login link if you’re not logged in, and show that you’re logged in if you are

One difference between what I do here and what was done in the original blog post is that the custom UserDetailsService is not a Grails service – it’s in src/groovy and not in grails-app/services. It wasn’t necessary to be a real service then and isn’t now; it’s a coincidence that the Spring Security interface name ends in “Service”. See the plugin documentation for general information about customizing this bean.

You can see the source for the custom bean here. By embedding the authorities in the user domain class, the many-to-many relationship is not needed and the model is a lot simpler, so the class implementation is also – for example there’s no need for a withTransaction block to avoid lazy loading exceptions.

The changes for the User class are fairly minor. You need static mapWith = 'mongo' if you have both the Hibernate and MongoDB plugins; in this case it’s unnecessary but harmless to leave it in. The id field should be an ObjectId, and I retained the other customizations from the earlier blog post (the embedded roles, the addition of the email field, extra constraints, etc.). The Role class changes are similar.

Since we’re using a custom UserDetailsService, we can delete the userLookup.userDomainClassName, userLookup.authorityJoinClassName, and authority.className properties from Config.groovy, and since the roles are embedded in the user class we can delete the generated UserRole class.

You should be able to clone the repo and start the application (assuming you have MongoDB and Grails 2.3.3 already). Click the login link on the start page and after you successfully authenticate, the link should be replaced by a message.

Converting Grails Applications to Plugins and vice versa

Monday, July 22nd, 2013

I was in London last week on vacation with my family and was lucky that there was a London GGUG meetup during my visit. David Dawson discussed modularizing Grails applications by refactoring them into multiple plugins (you can see the video of his talk here). One thing that he mentioned was the idea of plugins that can be run like standalone applications since the structures of Grails applications and plugins are so similar, and I thought it would be interesting to look at the process of converting an application to a plugin or a plugin to an application.

The approaches I’ll discuss here include a lot of bias on my part about how I like to create apps and plugins, so YMMV. I also won’t go into partial conversions since David covered this well in his talk.

So to convert an application to a plugin, the general workflow would be something like

  • Create the plugin descriptor, FooGrailsPlugin.groovy. The easiest way to do this is to run grails create-plugin pluginname and copy the generated file from there
  • delete everything from application.properties except the app.grails.version property
  • if you have jars in the lib directory that are available in a Maven repo, delete them and replace with BuildConfig.groovy dependencies
  • change any plugin and jar dependencies that are needed for development and testing but not when the plugin is installed to not be exported, by adding export = false
  • If you need the _Install.groovy, _Uninstall.groovy, or _Upgrade.groovy scripts (you probably don’t) grab those from the dummy plugin from step 1 (but delete any you don’t need, they’re all optional)
  • delete ApplicationResources.groovy if you aren’t using it and don’t depend on resources plugin
  • move code from BootStrap.groovy init() to FooGrailsPlugin.doWithApplicationContext and/or FooGrailsPlugin.doWithDynamicMethods and destroy() to FooGrailsPlugin.onShutdown, and delete BootStrap.groovy
  • add a dependency for the release plugin in BuildConfig.groovy
  • delete everything but the log4j configuration from Config.groovy
  • delete UrlMappings.groovy unless you have exported mappings; only keep the added ones
  • move bean definitions from resources.groovy to FooGrailsPlugin.doWithSpring and delete resources.groovy
  • delete grails-app/i18n message bundle files unless you added messages; only keep the added ones
  • delete everything from grails-app/views that you don’t use (in particular error.gsp, index.gsp, and layouts/main.gsp)
  • delete everything from web-app that you don’t use (including WEB-INF xml and tld files)
  • now would be a great time to write those tests you’ve been meaning to get to
  • create one or more test applications to install the plugin into to ensure that it works as a plugin; consider scripting this
  • write documentation for how to use the plugin; at a minimum a README file, but Grails gdoc files would be much better (run grails doc --init to get started)

Converting a plugin to an application is similar, except for the most part reversed:

  • Create a dummy application with grails create-app appname to copy missing files from
    • Move BootStrap.groovy, Config.groovy, UrlMappings.groovy, and ApplicationResources.groovy into grails-app/conf, merging if needed
    • Move resources.groovy into grails-app/conf/spring
    • Move message bundle files to grails-app/i18n, merging if needed
    • Move missing GSPs to grails-app/views
    • Move static resources from web-app
    • Move xml and tld files from web-app/WEB-INF
  • Move code from FooGrailsPlugin.doWithApplicationContext and FooGrailsPlugin.doWithDynamicMethods to BootStrap.groovy init(), and code from FooGrailsPlugin.onShutdown to destroy()
  • Move bean definitions from FooGrailsPlugin.doWithSpring to resources.groovy
  • Delete the plugin descriptor
  • Restore missing properties in application.properties
  • Delete the _Install.groovy, _Uninstall.groovy, and _Upgrade.groovy scripts
  • Remove the dependency for the release plugin from BuildConfig.groovy
  • Now would be a great time to write those tests you’ve been meaning to get to
  • If you make changes in the plugin’s doWithWebDescriptor, run grails install-templates and add them to src/templates/war/web.xml
  • If you add custom artifacts, or were supporting development-environment code or config changes in onChange and/or onConfigChange, these aren’t directly doable in an application. Use the pluginator plugin for these, and also for dynamic web.xml changes that require runtime logic

  • I’ve probably skipped a few steps and definitely omitted a lot of detail, but this should cover most of the process for each type of conversion.

This Week in Grails (2013-20)

Saturday, May 25th, 2013

The big news is that Grails 2.3 M1 was released. 2.3 will be a big update with many fixes, enhancements, and new features. M1 only has a subset of what’s coming and it’s already packed with cool new stuff. Graeme did some writeups on what’s coming, Grails 2.3 M1 and Upcoming M2 and Road to Grails 2.3: RESTful URL Mappings and URL Mapping Reports.

Be sure to check out this cool video on Grails that the folks at Orange & Bronze created.

I released two plugins, standalone-tomcat-memcached and standalone-tomcat-redis. These are like the database-session plugin in that they reconfigure the web server to store session data in a datastore instead of the traditional approach, but these only work with Tomcat since they work directly with the Tomcat APIs instead of intercepting and replacing the real sessions. I’ve been working on reconfiguring how Grails applications deploy to Heroku, changing from using an embedded Jetty instance to using the standalone plugin (either with Tomcat or Jetty). Along the way since Heroku doesn’t support sticky sessions I created these plugins to get things working smoothly with the heroku plugin. More on this later.


If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.


Translations of this post:



Plugins

There were 7 new plugins released:

  • apidocs version 0.1. Generates REST API documentation
  • criteria-js version 0.3. GORM criteria for JavaScript
  • db-helper-rest version 0.3. Provides methods for dropping, creating and initialization of database schema from the project bootstrap
  • httplogger version 1.0. Logs HTTP traffic
  • required-parameters version 1.0.0. Enables verifying required parameters for controller actions using simple annotations
  • standalone-tomcat-memcached version 0.1. Uses Memcached as the Tomcat session manager
  • standalone-tomcat-redis version 0.1. Uses Redis as the Tomcat session manager

and 26 updated plugins:

  • goodform version 1.0.2. Create extremely usable complex forms with rules based flow that work well in browsers
  • airbrake version 0.9.3. Notifier plugin for integrating apps with Airbrake
  • asynchronous-mail version 1.0-RC5. Send email asynchronously by storing them in the database and sending with a Quartz job
  • aws-sdk version 1.4.3. Use the Amazon Web Services infrastructure services
  • closure-templates-resources version 0.2.3. Supports server-side compilation of .soy template files to JavaScript files
  • easyui version 1.3. Supplies jQuery EasyUI resources and taglibs
  • external-config-reload version 1.3.0. Polls for changes to external configuration files (files added to grails.config.locations), reloads the configuration when a change has occurred, and notifies specified plugins by firing the onConfigChange event in each
  • font-awesome-resources version 3.1. Integrates the Font Awesome icon set
  • google-visualization version 0.6.2. Provides a taglib for the interactive charts of the Google Visualization API
  • grails-melody version 1.44. Integrates the JavaMelody system monitoring tool
  • hibernate version 3.6.10.M3. Provides integration between Grails and Hibernate through GORM
  • i18n-fields version 0.6.4. Provides a declarative way of localizing domain classes’ fields for different languages
  • jrimum-bopepo version 0.3. Allows you to create Boletos Bancarios for Banks of Brazil using the Jrimum Bopepo library
  • neo4j version 1.0.0.RC2. GORM for Neo4j
  • newrelic version 1.0-2.18.0. Adds the NewRelic Real User Monitoring feature to your GSP pages
  • pusher version 0.5. Wrapper for pusher.com REST api
  • recaptcha version 0.6.5. Integrates ReCaptcha and Mailhide services
  • remote-pagination version 0.4.4. Provides tags for pagination and to sort columns without page refresh using Ajax and loads only the list of objects needed
  • segmentio version 0.2.0. Use Segment.io to send your analytics data to any service you want, without you having to integrate with each one individually
  • spring-security-mock version 1.0.2. Mock authentication support for Spring Security
  • standalone version 1.2.1. Runs a Grails application as a JAR file with an embedded Tomcat server
  • vaadin version 1.7.5. Adds Vaadin (http://vaadin.com/) integration
  • validate-config version 0.4.2. Adds methods to ConfigObject for validating expected and required properties
  • war-exec version 1.0.3. Makes the war files generated by Grails executable (java -jar myapp.war) by embedding Jetty. Jetty can be configured using properties in Config.groovy
  • webdriver version 0.4.2. Integrates Webdriver with Grails to allow functional testing in both HtmlUnit and real browsers
  • xwiki-rendering version 1.0-RC3. Convert texts using XWiki Rendering Framework

Interesting Tweets

Jobs



User groups and Conferences

This Week in Grails (2013-17)

Tuesday, May 07th, 2013

We released Grails 2.1.5 and Grails 2.2.2 this week. Grails 2.3.M1 is tentatively planned for next Tuesday will be released soon.

I linked to Peter Ledbrook’s Where next for Grails? post previously and there have been two interesting followup posts, one from David Dawson and one from Graeme.

Ticket sales for GR8Conf EU end soon, so be sure to get yours.

Several new Grails presentations have become available:

Programming Grails is printing, and I got my copy this week. You can get yours at the O’Reilly website and at Amazon, and there is also a sample chapter available. You can save 50% until May 8th.


If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.


Translations of this post:



Plugins

There were 5 new plugins released:

  • jquery-date-time-picker version 0.1.0. Makes it easy to use jQuery date and time pickers
  • keywords-and-tags version 0.1. Provides a taglib able to highlight keywords/tags on your pages for SEO purposes
  • poly-driver version 0.2. Lets you specify a different preferred browser for each specific Geb specification class in a test suite
  • restrpc version 0.1. RESTRPC is an interceptor api that allows the user to associate more than one method/function per request method while still being compliant with the REST standard thus creating a ONE-TO-MANY pairing
  • scaffolding version 1.0.0. Handles the configuration of dynamic scaffolding

and 25 updated plugins:

  • atmosphere-meteor version 0.4.3. Incorporates the Atmosphere Framework (https://github.com/Atmosphere/atmosphere/wiki) and can form the basis for a traditional XMPP server with a browser-based client without the limitations of BOSH
  • aws-sdk version 1.4.2. Use the Amazon Web Services infrastructure services
  • barcode4j version 0.3. Generates barcodes using http://barcode4j.sourceforge.net/
  • build-test-data version 2.0.5. Enables the easy creation of test data by automatic inspection of constraints
  • cors version 1.1.0. Installs a servlet filter to set Access-Control-Allow-Origin and other CORS related headers to enable cross site AJAX requests to your Grails application
  • database-migration version 1.3.3. Official Grails plugin for database migrations
  • dojo version 1.6.1.17. Integrates the Dojo javascript toolkit
  • easyui version 1.0. Supplies jQuery EasyUI resources and taglibs
  • filterpane version 2.1.5. Adds filtering capabilities
  • hibernate version 3.6.10.M1. Provides integration between Grails and Hibernate through GORM
  • html5-mobile-scaffolding version 0.6.1. Scaffolds HTML5 mobile application using jQuery mobile in a single page
  • jaxrs version 0.8. Supports the development of RESTful web services based on the Java API for RESTful Web Services (JSR 311: JAX-RS)
  • marshallers version 0.3. Easy registration and usage of custom XML and JSON marshallers supporting hierarchical configurations
  • multi-tenant-single-db version 0.8.3. Multi tenant setup focused on single database mode
  • plastic-criteria version 0.9. Mock Grails Criteria for Unit Tests
  • plugin-config version 0.1.8. Simplifies plugin configuration tasks
  • quartz version 1.0-RC7. Schedules jobs to be executed with a specified interval or cron expression using the Quartz Enterprise Job Scheduler
  • recaptcha version 0.6.4. Integrates ReCaptcha and Mailhide services
  • release version 3.0.0. Publishes Grails plugins either to a public or private repository
  • rendering version 0.4.4. Render GSPs as PDFs, JPEGs, GIFs and PNGs
  • spring-security-facebook version 0.14. Plugin for Facebook Authentication, as extension to Grails Spring Security Core plugin
  • tomcat version 7.0.39. Makes Tomcat 7.0 the default servlet container for Grails at development time
  • vaadin version 1.7.4. Adds Vaadin (http://vaadin.com/) integration
  • validate-config version 0.4.1. Adds methods to ConfigObject for validating expected and required properties
  • zk version 2.2.0. Adds ZK Ajax framework (www.zkoss.org) support to Grails applications

Interesting Tweets

Jobs



User groups and Conferences


This Week in Grails (2013-15)

Saturday, April 20th, 2013

The Groovy team released Groovy 2.0.8 and 2.1.3 this week.

Peter Ledbrook wrote up some thoughts about the future of Grails on his blog.

Check out this recent GGUG talk on Grails services, command objects and design approaches.


If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.


Translations of this post:



Plugins

There were 3 new plugins released:

  • grooscript-vertx version 0.2.5. Convert your Groovy files to Javascript
  • search-fields version 0.1. Auto-generate search query based on DSL in domain classes
  • yui-war-minify version 1.2. Runs yui-compressor on css and javascript resources at WAR creation time

and 11 updated plugins:

  • build-info version 1.2.4. Provides a controller/view that display basic information about the war file
  • coffeescript-resources version 0.3.8. Create coffeescript modules that automatically compiles on every file change with jCoffeeScript
  • cxf version 1.1.1. Expose Grails services as SOAP web services via CXF
  • cxf-client version 1.5.3. Use existing (or new) Apache CXF wsdl2java generated content to invoke SOAP services
  • easyui version 0.9. Supplies jQuery EasyUI resources and taglibs
  • ember-templates-precompiler version 0.4.1. Precompiles EmberJS powered Handlebars templates
  • envers version 2.1.0. Integrates with Hibernate Envers
  • filterpane version 2.1.3. Adds filtering capabilities
  • gson version 1.1.4. Provides alternate JSON (de)serialization using Google’s Gson library
  • paypal version 0.6.9. Adds PayPal integration
  • uploadr version 0.7.3. HTML5 Drag and Drop file uploader

Interesting Tweets

User groups and Conferences

This Week in Grails (2013-14)

Sunday, April 14th, 2013

SpringSource has moved from VMware to EMC as part of Pivotal. Check out Adrian Colyer’s blog post for information about how this will affect Grails, Groovy, and Spring and what the future looks like for us.

The Groovy team did an extensive interview with ZeroTurnaround, lots of interesting stuff there.

Happy Birthday to Grails, the 0.1 release was 7 years ago.

I wrote a blog post about a new plugin that integrates Netty with Grails. It will probably take an integration into Grails core to see real benefits, but there should be some opportunities to improve scalability and performance with this plugin.


If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.


Translations of this post:



Plugins

There were 3 new plugins released:

  • domain-locking version 0.3. Provides an easy way to use optimistic/pessimistic lock
  • nettymvc version 0.1. Adds support for using Netty in Grails
  • typescript version 0.4.1. Helps you manage typescript code in your Grails application

and 16 updated plugins:

  • facebook-sdk version 0.4.10. Allows your application to use the Facebook Platform and develop Facebook apps on Facebook.com or on web sites (with Facebook Connect)
  • file-server version 0.2. Serves files from any directories on disk
  • force-response-download version 0.1.5. Forces the browser to open a dialog for downloading content produced within controller actions
  • geasyui version 0.8. Supplies jQuery EasyUI resources and taglibs
  • geb version 0.9.0. Geb is a library for headless web browsing on the JVM, suitable for automation and functional web testing
  • gorm-interceptors version 0.1.1. Interceptors for GORM methods (excluding find, countBy, addTo, removeFrom methods)
  • gson version 1.1.3. Provides alternate JSON (de)serialization using Google’s Gson library
  • handlebars-resources version 0.3.6. Supports using Handlebars.js templates with the Grails Resources Plugin
  • plastic-criteria version 0.8. Mock Grails Criteria for Unit Tests
  • remote-pagination version 0.4.3. Provides tags for pagination and to sort columns without page refresh using Ajax and loads only the list of objects needed
  • sharding version 1.0. Defines multiple database shards to horizontally scale data
  • slug-generator version 0.3.1. Generates unique slugs for String properties, for example to generate unique ‘nice’ urls for access to domain objects
  • spring-security-twitter version 0.5. Twitter authentication as extension to the Spring Security Core plugin
  • uploadr version 0.7.2. HTML5 Drag and Drop file uploader
  • vaadin version 1.7.3. Adds Vaadin (http://vaadin.com/) integration
  • zkui version 0.5.6. Seamlessly integrates ZK with Grails’ infrastructures; uses the Grails’ infrastructures such as GSP, controllers rather than zk’s zul as in ZKGrails plugin

Interesting Tweets

Jobs



User groups and Conferences

Grails and Netty

Monday, April 01st, 2013

With all of the buzz about the Play vs Grails Smackdown at Devoxx last week, and this framework benchmark comparison from TechEmpower, I thought it would be interesting to look again at Rossen Stoyanchev’s demo project that integrates Spring MVC with Netty. He had mentioned it on the SpringSource internal developer list and I bookmarked it for later since I was curious about Netty.

I spent the weekend converting Rossen’s code to work with Grails, and created a plugin, borrowing some code from the Spring mock Servlet API classes and also from Tomcat. It’s a weird plugin in that it runs concurrently with the regular web app on a different port. I’m currently taking advantage of the work that Grails does, e.g. creating the Spring ApplicationContext, compiling GSPs in production WARs, etc. But it should be easy enough to get it to run standalone. It’s similar to the Dropwizard plugin, which also adds an alternative and higher-performance request path within a Grails application.

Netty is a generic (but high-performance) network library, so it doesn’t have extensive support for the Servlet API. But it does support HTTP, and that’s what Rossen’s code and my version add – a bridging layer between the lower-level Netty approach and the Servlet API. Ideally this provides a performance and scalability boost from Netty’s non-blocking IO, with the familiarity of the request/response/session approach in the Servlet API.

Most everything works in the plugin, but there are some omissions. There’s no support for SSL, and file upload isn’t implemented. You can do all of the usual Grails stuff, i.e. use controllers, services, GORM, etc. There is support for HTTP Sessions, although they’re not serialized to disk at shutdown and there’s no support for distributed sessions. But other than these items, making requests on the Netty port should work pretty much the same as requests on the servlet container port.

You can install the plugin in the usual way, i.e. add this to BuildConfig.groovy

compile ':nettymvc:0.1'

It will start a server socket on port 8080 by default, but you can configure that in Config.groovy, e.g.

grails.plugin.nettymvc.port = 8090

The plugin page is here and the source is here. Please try it out and let me know if there are issues or if you have suggestions for improvements, ideally in the form of pull requests of course :)

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.