Chapter 5 - Authentication with JSecurity Plug-in

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.
Part 3 of this series can be seen here.
Part 4 of this series can be seen here.
Part 5 of this series can be seen here.

Many applications require security. Luckily, through Grails plug-in architecture and a number of available plug-ins devoted to the task, adding security a Grails application is relatively easy. In this chapter, Jon takes us through implementation of many normally encountered requirements using the JSecurity plug-in. I have only used the Spring Security (Acegi) plug-in prior to this, so I really looked forward to the experience (I have read about JSecurity and CAS previously). My impression after this chapter is that implementing JSecurity via the plug-in is a fairly simple process and is one I'll strongly consider on future projects. The only caveat to this is the same complaint I've had of features the book covered earlier, namely the decision to "roll your own" rather than using the supplied commands to create artifacts and teaching and modifying those. In the end, I am not sure what it is I don't know and will be forced into digging into the features of the plug-in before I use it. Certainly, this being a tutorial, a few additional pages covering the plug-in in greater detail does not seem unwarranted.

The chapter starts off introducing us to the fact that there is a plug-in mechanism and tells us of several of the many areas for which plug-ins have been written. Jon explains that plug-ins can generate a number of artifacts, from classes to static resources, and can take part in build and runtime events. Further, he states that the core features of Grails are implemented as plug-ins, thus making the plug-in architecture fundamental to Grails, and provides the sample of GORM as a core plug-in, the plug-in used to abstract Hibernate.

It seems that the reason JSecurity was used in the project is the ease with which it could be integrated with the existing domain model. This proved to be true, in my opinion.

Jon explained that plug-ins are installed in a default directory, your user account. He then states that this gives rise to a number problems and provides two:

• Other users may not be able to execute the plug-in.
• If the name of the project is changed, you must remember to dig around in your user directory to change the installation location of the plug-in.

I am not sure that these are truly serious concerns. Perhaps they are on larger projects than those on which I've worked. He then tells us how to override the default plug-in location, putting it into another location. Prior to Grails 1.1, the default location was within the project tree. With the change, a number of people had problems and one of the common solutions suggested on the mailing list was to do what Jon demonstrates here, except to use the path as had been used in earlier releases. I personally now just use the default. However, I followed Jon's instructions. What I found, and it could be a user error, is that my editor, Intellij IDEA, did not recognize the path specified in the BuildConfig.groovy file causing a cannot resolve symbol JSecurity error when I created the TeamworkRealm.groovy file. This error is specific to the browser. There were no problems building the project outside of IDEA. I did try many possible solutions, and think I covered them all, but no "solution" worked. So, I just ended up installing the plug-in into the default directory. But, I digress.

He went on to explain more about the structure of plug-ins, which is certainly nice to know information. He then tells us of the scripts the JSecurity plug-in makes available to the developer. However, we are then told that one will not be used because the default domain model generated is more complicated than the simple model used by the application. We do eventually use the CreateAuthController script to generate the login action and page.

We are then provided a quick overview of JSecurity, covering the role, permissions, subject, principal and realm concepts. Permissions are not used in the application. Realms are delved in more deeply than the other subjects, and then we go on to creating our own realm. There are a couple scripts supplied by JSecurity for creating realms, CreateDbRealm and CreateLdapRealm, that are not used. What these create should be self evident from their names.

Next, we go on to implementing the authenticate method in the realm. This gives rise to a discussion of dynamic finders. This is covered relatively sufficiently. Explaining how the term dynamic is derived from dynamically constructed method names rather than the fact that the methods are added to the domains dynamically, he covers all the operators that can be used when constructing a name. He rightly implies that the junction operators And and Or are limited to two conditions. This could easily be missed by the noob and gives rise to one of my complaints about Grails. For example, you may write a finder such as Book.findAllByAuthorLastNameAndPublicationDate(name, date). This is perfectly legitimate. When you try running your code with finder Book.findAllByAuthorLastNameAndPublicationDateAndBinding(name, date, binding), you'll find that it fails and will have a large stack trace on the console. You cannot have three conditions. This violates the principle that you should always write your code so that someone else has a clear mental model of what to expect. Unless you've read the one line in the Grails document that points this out or you've properly inferred from other writings, and it has stuck with you, you will run into this error. Perhaps this is a problem with the underlying Hibernate implementation. Either way, it is wrong. Never make people guess. I digress again.

From here we are introduced to the use of criteria for more complex queries. This is barely touched upon, but we are promised that we will get a deeper introduction in a later chapter.

Then come the concepts of filters. These are similar to filters in Java Servlets. They are quick and easy to implement. And, soon, we have our first filters written.

Because the authentication is in place, we are not able to log into our application. There are no users! So, Jon takes us through adding users via our bootstrap class and we are introduced to the encryption function provided by the plug-in. This gives us the required background for encrypting the password when the user is created or updated. Jon did teach a trick here of which I was unaware. He updated the password field after calling hasErrors and save. This takes advantage of the Open Session in View pattern for hibernate. This means that changes to your object will not be persisted until all server-side operations have finished.

Finally, we add some other features to our application: an improved permission denied page, a sign out link, and displaying the author of our messages. In the latter, we are introduced to services briefly and told we will learn more about services in an upcoming chapter. We are told that Grails supports the concept of a service layer, though little more. We are also required to relate messages to users. This was done simply, but Jon does not use belongsTo or hasMany properties to do so. We are also introduced to Hibernate's lazy loading feature, the n + 1 problem to which this gives rise, Hibernate fetch strategies, and using the eager strategy to resolve the n + 1 problem.

One error was found in the code listings in the chapter on page 100. It is fairly minor. The author wrote Sha1Hash(user.password).toHex() and it should read Sha1Hash(userInstance.password).toHex(). I've submitted an error report to the publisher. Hopefully it will show up on the errata soon. Similarly, there was an instance where he used the word principle rather than principal on page 89 in the text that was not listed in the errata. I have not submitted this and likely will not.

Chapter 4 - Introduction To Groovy

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.
Part 3 of this series can be seen here.
Part 4 of this series can be seen here.

Chapter 4 is the obligatory Groovy introduction. An in-depth introduction is not called for and has no place in an introductory Grails book. When it becomes necessary to have a deeper understanding, I recommend reading Groovy In Action by Koenig, et al, or Programming Groovy by Subramaniam.

The chapter starts off with a brief introduction of Groovy and where it fits in the pantheon of languages. For those new to Grails, any fear of needing to learn a new language is quickly dispelled by showing how closely Groovy resembles java and how well it integrates with java. Of course, this only applies if you are currently a java programmer. Jon makes it clear that almost anything written in java can be run as Groovy, unfortunately, at no point does he tell us where this isn't the case. A simple pointer to the Differences from Java and to the Things you can do but better leave undone pages on the Groovy site would have been helpful.

He covers all the basic features: everything an object, semicolons being optional, strings, GStrings, slashy strings, numbers, lists, maps and ranges. Truth and equality are likewise covered. Closures are explained. Closures are very important for the budding Groovy programmer. An understanding of closures is absolutely necessary for Grails development. Jon goes on to explain Plain Old Groovy Objects and how metaprogramming is used to add dynamic behavior, including how to use invokeMethod. This is a very interesting feature and goes to the heart of dynamic programming for those unfamiliar. While this knowledge is not critical to the Grails newbie, it is nice to know, and we are told that we will do more with it in a later chapter while developing a plug-in. Dynamic interception of calls is heavily used by Groovy Builders, which is the last section covered in the chapter.

Armed with the knowledge in this chapter, we should be able to build a fairly sophisticated application.

Chapter 3 - Posting Messages

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.
Part 3 of this series can be seen here.

The beginnings of the business goals of the project are implemented with this chapter. We create a new domain, Message, two views, one for adding messages, the other for viewing, along with corresponding controllers. Along the way, we learn about binding, validation and other user messages, the flash scope, redirection, the domain list method, several gsp (Groovy Server Pages) tags, layouts including the main.gsp and how SiteMesh renders layouts, and securing the site from XSS (cross site scripting) attacks.

There were a few small mistatements or errors. First, when explaining how dateCreated and lastUpdated properties can be added to domains and will be updated for free, he states that they must have the corresponding constraints set to nullable:true. The corresponding example shows this, as well. Setting these properties to null is unnecessary. To be fair, this could've been true in an earlier release of Grails.

The second issue is really minor. At one point Jon suggests you use the BootStrap.groovy to create some initial messages then says you can view the home page and see these messages. What he fails to mention is that the application needs to be restarted to pick up the changes to the BootStrap.groovy (unless that was just some strange issue on my side, but I think not).

The final error was when HTML encoding was discussed. We are instructed to make the highlighted changes, though the code sample has no highlighting. I trust experienced developers can overcome this.

In earlier chapters we were introduced to some command line arguments for creating domains and controllers. In this chapter, however, we are never introduced to generate-views. I thought this curious. Yes, generate-views would create several unneeded views, but I feel this being an introductory text, it would be better to demonstrate the command and direct the reader to delete the unnecessary views. The positive side of having the reader hand code the views is that it makes it far more obvious how various code fragments relate to the other parts of the application, as well as the introduced GSP tags.

At the end of this chapter, the reader should now have an understanding of the basic building blocks of Grails. This chapter covered a lot of territory. Even so, it seemed simpler than the previous chapter, likely because domain development is so fundamental to most applications. Readers should have at this point a good idea of how rapid development can be with Grails.

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.

Preface and Chapter 2 - Managing Users with Scaffolding

Most developers realize early in their career that there are many ways to write an application that are essentially valid. Differing levels of knowledge of practices or of available tools and frameworks lead to different decisions. Likewise, greater knowledge of a domain likely means a more nuanced design. Then there is the ever present pressure to deliver a working application within a set of existing constraints that will force different decisions. Similarly, authors would likely make different choices in the way information is presented. Unlike Beginning Groovy and Grails and Grails In Action, Jon Dickinson chose not to present the user with a chapter on Groovy after the introductory chapter. Rather the intent seems to be "learn by example". I have to admit that I felt a bit uncomfortable with this, which I attribute to my already existing knowledge of Grails and the fear that a newbie would be lost or confused by what was left out. That said, just about all the Groovy tidbits to which the reader would be exposed in the chapter that he/she would likely not understand had some explanation. Coupling that with the knowledge that chapter four will explore Groovy in greater detail, my concerns may be unfounded.

The chapter starts off with a brief explanation of scaffolding, what purposes it serves and what expectations one should have for the created artifacts. This is important knowledge to share. It reinforces the idea that Grails provides a means for rapid exploration of the problem domain. After explaining that scaffolding is generated from the domain definitions the developer creates, he goes on to explain just scaffolding does in terms of providing actions and views.

We are then walked through the creation of our first domains, a User domain and a Role domain. Here Jon makes a statement I feel a bit misleading, "Domain classes constitute the domain model for the application. They are mapped directly to database tables by the Grails framework...". [emphasis mine] This is not exactly true, but is probably true enough for the novice. However, I believe the beginning Grails developer should be aware that there are circumstances where domains are not one-for-one equivalent to database tables, nor are attributes necessarily one-for-one. Perhaps this will be addressed in the later chapter on GORM. Jon also provides the excellent advice to of placing your Grails classes in a package. Grails by default creates all classes in the default package.

After the two domains are created, Jon leads us through creating controllers to enable scaffolding. He shows us how to create a controller through the grails command line command create-controller. We do this for both the User and the Role and we learn that both a controller class and a unit test class are created (unit tests were likewise created when the domains were created). A deeper discussion might have been warranted here to discuss the differences between create-controller and generate-controller. I can only surmise that his reasons for choosing the former to retain flexibility, to have a minimal implementation of controller logic for as long as possible while one prototypes the domain. I personally do the latter because I often find a need to start changing behavior early on. Being that the domain model is likely the most difficult aspect of the type of development for which Grails is targeted, his approach may be wiser. It is something I will integrate into my personal practice when I build my next Grails application.

The next section walks through constraint definition. Constraints, we are instructed that constraints, defined in the domain classes, serve three purposes: to perform basic validations of the data, to control the ordering in which the fields are displayed in our views, and to determine which input types are used when forms are rendered. The last is true precisely because we have yet to define any views and are just using the default views provided by the scaffolding. Jon provides us with a table of constraints that are available to the developer. Developers should have been cautioned, in my opinion, that some of the constraint definitions have an impact on table definitions, while others do not.

After defining constraints, the chapter turned to creating relationships between tables. Since there are only two domains present in the application thus far, he only demonstrates the creation of a one-to-many relationship between Role and User. The reader is somewhat mislead here by the suggestion that he must add several pieces of code to the Role class when only the statement static hasMany = [users:User] is necessary. I presume a competent developer would likely understand that neither the addition of the constraint, nor the addition of the toString method is necessary to the relationship definition. The toString method definition, by the way, has the unnecessary access modifier public specified. The default visibility of Groovy methods is public.

The final section is about using the BootStrap class to load data into the database at startup. At this point in the book project, we are still using the pre-configured HSQLDB, an in memory database. Personally, I feel it is a best practice to avoid creating a physical database as long as possible. Thus, this is a practice I use extensively. Of course, if your project involves legacy tables, you will not have such luxury.

This is a chapter full of red meat for the aspiring Grails developer. Though we have only just begun, much has been learned about application development using Grails.

Part 1 of this series can be seen here.

Preface and Chapter 1 - Getting Started With Grails

The preface covers the usual subjects one would expect in a preface: an introduction by the author, what the book covers, who the book is for, and conventions and symbols used throught the book. There were a few small syntax issues that in no way detracted from understanding. My concern with this, though, is that if these simple syntax problems show up so early in the book, does this foreshadow editing issues in later chapters, especially where it is highly technical? The errata currently shows only one issue, and it, too, appears to be only a small typo.

Chapter 1 makes an argument for using Grails, one that is pointed to individuals developing websites using java technology. It makes no attempt to sway those using Rails, for example, to jump to Grails, nor does it compare Grails technology to other frameworks/technologies available. The argument boils down to helping developers provide value more quickly. This is acheived through six items: less configuration; faster setup; shorter develop/test cycles; consistent development environment; a web domain specific language (DSL), and fewer dependencies. None of these are argued exhaustively. No hardcore skeptic will be convinced, but, then, the person purchasing this book is probably already somewhat sold, has probably already heard similar arguments, and is now exploring Grails to see if the hype lives up to the promise.

From there, the book covers installation. Installation is dealt with quickly and with little detail, as it should be. A professional developer should be able to handle this easily on his/her own. I wouldn't be surprised if most readers of the book don't already have it installed before they read the book.

Creating an application is next. Again, creating applications is relatively trivial, but this is a necessary explanation for the Grails newbie if for no other reason than to provide explanations of the various directories that are created. Without having done anything than running the create-app script, he shows, too, that you have a working application by launching it from script run-app. Yes, it is an application that doesn't do anything, but it provides the framework for further development.

The chapter concludes with an overview that author will use throughout the remainder of the book, a team communication portal, and the technologies that will be included in the application.

I was asked by Packt Publishing to review Grails 1.1 Web Application Developement by Jon Dickinson. This is the first part in the series. You can download a sample chapter, Chapter 10: Managing Content through Tagging from the publisher's site.

As I read through the book, I will post additional entries and reference the previous entries. So, no matter where you come into this, you can read through all posts.

When reviewing any subject matter, one should be aware your own perspectives and biases. I have been working with Grails professionally for about six or seven months now. I have read several books in the Grails sphere: the freely available Getting Started With Grails by Jason Rudolph on InfoQ, which is hopelessly outdated, Beginning Groovy and Grails by Judd, Nusairat and Shingler, Grails in Action by Smith and Ledbrook, and Grails Persistence with GORM and GSQL, which I previously reviewed here. When I say I've read these books, I have not read any from cover to cover except for Grails Persistence. I am what Mortimer Adler defined as a syntopical reader. I read to gain an understanding of particular subjects and bounce from book to book as necessary (of course, I google, read blogs and mailing lists, too). This is especially true when I am working on a project using what is a new technology to me. The point of explaining this is so that you, the reader, have a better idea of where I am coming from. I am now at a point in my Grails knowledge that I would not likely seek out another introductory book. I definitely need to get into meatier, deeper explorations. That said, I believe I can maintain a relatively objective view of this book.

My next post will be about what I've read to date.

My last project collapsed suddenly, unfortunately. I now find myself looking for a new assignment. In the meantime I am working on a website for Lone Star Custom Pits and Grills, a pro bono project. Lone Star is a manufacturer of customized, mobile barbecue pits used for competitions and catering. This project is made a bit more difficult than others as the owner is in Houston and is on the road a lot delivering pits. Thus, my contact with him is somewhat limited and will likely slow the delivery time. Being a pro bono project, too, the work on this project takes a back seat to finding new employment and organizing the GR8 conference here in Minneapolis.

The first feature is to create a "Pit Builder". This will allow potential customers to choose the features and options they want on a pit. This is a largely straight-forward affair with most of the difficulty coming in the form of the Ajax and CSS than in anything in the domain. The only gotcha in the domain is that there is heirarchical relationship between several domains. For example, a smoking chamber IS A component. There are many sub-components. This, so far, has not caused any issue at all. Inheritance of grails domains is simple. Some form of management system will be created with the pit builder as well.

Along with the pit builder, the site look and feel will also have to revamped before rolling out the pit builder. After that is complete, we'll likely add a blog. There will likely be other features added as well.

Since this project is pro bono, I am much more able to discuss details and hope to blog about it here. I will also use this as a basis for other things, perhaps screencasts, etc.

The night before I left for Copenhagen to attend the GR8 conference there (www.gr8conf.org), several members of my local GUG, Groovy Users of Minnesota (GUM), started to discuss holding a similar conference in the Midwest. All the speakers at GR8 stated to me that they'd be open to coming, depending on timing and other commitments. I also spoke with Søren Berg Glasius, the organizer of the Copenhagen conference. He suggested branding our conference with the GR8 name, something we seem to have decided to do.

The planning for this conference is in the earliest of stages. We are looking at late September or October dates. Likely it will be a two day conference, probably a Thursday and Friday event. We may add a third day if there is enough interest. I'll be reviewing a possible venue today. Next week I expect far more details and organization to occur. I'll continue to share details as they become available.

When writing a tool
comments are cool
and todos are too
Aye

Today is the first day of the GR8 conference. It should prove exciting. Several top people speaking here: Graeme Rocher, Guillaume Laforge, Dierk König and Jim Shingler. I am really looking forward to the talks Designing your own Domain-Specific Languages, Grid Computing for Real-Time Computational Finance: A Case Study with Groovy and Grails and Groovy usage patterns.

More later.