Original Source

Dave Cherry has written a step-by-step guide for setting JEE style role based authentication (that means realms) as a way to secure your Grails application. This guide is not for the faint of heart, it requires you to roll your sleeves and edit a couple of files residing in your GRAILS_HOME directory, not your project_home directory, meaning the changes will be system wide and not project wide. Despite this minor inconvenient Dave is sure to point to alternatives and other useful JEE security links that will help you along the way.

JEE role based security provides a means of controlling access to resources configured at the application server level. On some larger projects or within corporations this type of access control may be mandated. Due to the fact that the application server controls the security, several applications can share the same realm and therefore share the same credentials, this can be a big plus on large websites, spanning multiple applications.

If you are not familiar with role based authentication look at Using Role based security and tomcat realm how to. Also note that Grails has other options for handling security including the ones listed here grails security plug-ins.

In order to use role based authentication with Grails, several changes are required. Unfortunately one of the cases requires that the actual runtime be changed. However, this change is very straightforward and documented here. Note any references to grailshome, actually refer to the directory where Grails itself is installed and not a Grails project.

Continue reading the full article at The Coder’s Corner.

Tags: Dave Cherry, Grails, Howto, Security

Original Source

Dave Cherry has written a GORM guide.

GORM is the data abstraction layer that is used to map domain objects to database tables in Grails. Although GORM can be used outside of Grails, we do not discuss that here, we assume that you are using Grails. In fact we assume you are using V1.0 of Grails.

Grails gets you started quickly, when you create a new project, setting up the database for development should not be required, this is because Grails creates a default datasource that uses an in-memory database.

Unlike Ruby on Rails, GORM starts with the definition of a POGO (groovy object). This object is then used as the template to build the table on the database. Although this can be changed, it is by convention the default way. This article assumes that you are familiar with Grails, and have already created a test project that can be used for this article.

Though GORM depends on some bootstrap code done by Grails core, you can pretty much use it outside of Grails, as Jeremie Wilden shows at Using GORM in a Desktop Application. Dave takes care to point out a crucial difference from RoR: domain models are the primary building blocks in Grails, not the database. These means you are free to model your domain without being restricted by a particular database schema. Usually what happens with a brand new Grails application the database will follow the domain. Then again, because Grails follows the Convention over Configuration paradigm but doesn’t dismiss configuration, you’ll be able to map a legacy database schema to a freshly designed domain. This means you do not have to throw away your current web application in order to take advantage of Grails.

Dave outlines the basics of a domain model, how to map domain constraints which will be reused on views and database schema generation. He also demonstrates two of the three supported relationship mappings

• one to many
• many to one

Leaving the many-to-many relationship without example because of the following

If you’ve used Hibernate before, you may be used to mapping many-to-many tables in an invisible way, at the moment GORM does not provide this. Instead the join table must be included in your domain model; then you use the many-to-one and one-to-many support we’ve already seen.

For example if added a ‘Keywords’ object that linked to many Books, and each Books could have many Keywords, we would create a new domain object something like KeywordBookLink that had a one-to-one link with both Keyword and Book. In addition it would be wise to make either Book or Keyword the owner of the link object.

Though it looks like a limitation of Grails/GORM, Graeme Rocher and Dierk König have said before that an explicit joint table is in fact a good idea. Once you reflect on why you need it you may discover additional properties that can be applied to the relationship itself that do not belong to either side per se.

Other topics discussed in the article are

• basic CRUD operations
• dynamic listings
• dynamic finders

the article is not a full description of what you can accomplish with GORM, but it is a very good read for those wanting to learn one of the most powerful tools in the Grails toolbox.

Tags: Dave Cherry, Grails