A common requirement in webapps nowadays is to switch users between a secure and insecure connection (called protocol switching). For example, maybe your user needs to enter a password, credit card number, or some other sensitive information. Of course, you (and the user) would like that information to be sent securely, which means requiring https. Assuming you’ve already got a server set up with an SSL cert and it’s ready to serve pages over SSL, you’ll need to ensure your webapp serves all secure pages over https. Unfortunately, this isn’t always as easy as it seems. But it’s not too tough either, thanks to Grails and Spring Security.

Here are the requirements for protocol switching:

• Serve secure pages using https, regardless of the link used to get to the page (i.e. http links should be redirected to https)
• Make protocol switching transparent to the majority of your application (i.e. links starting with http:// will automatically get redirected to https:// and vice versa)
• Easy configuration of which resources must be served as secure, insecure, or either (i.e. images, CSS, and JavaScript should be loaded using the same protocol the page uses to avoid nasty browser warnings (see below))
• Security and protocol switching should be handled in a way such that browsers aren’t continuously popping up warning dialogs
• Make it work in Grails

Implementation

There are several ways to go about automatic protocol switching. One of the most popular would be to use Apache and mod_rewrite. That solution works fine, but it’s not portable between different types of servers.

The solution below is pure Java, and is portable between any servlet container. By the way, this isn’t a Grails only solution – this will work with pretty much any Java web stack – the only thing that will differ is how you wire things up. In fact I’ve used this in a regular Spring MVC app with a regular Spring configuration…but I’m only going to show the Grails way to do it today.

Here’s how to get automatic protocol switching in Grails:

• Add a filter definition to web.xml that intercepts all requests and handles the protocol switching and redirecting
• Configure which URLs require which protocol
• Test!

Adding the filter definition

Spring Security has protocol switching built in, so why reinvent the wheel? (Don’t worry, you don’t need to use any other parts of Spring Security to get protocol switching.) Spring Security refers to protocol switching as Channel Security, but don’t worry, it’s the same thing.

If your Grails app isn’t already using Spring Security, add the following dependencies into grails-app/conf/BuildConfig.groovy to have Grails download the required JARs:

grails.project.dependency.resolution = {

	// ...
	// other settings...
	// ...

	dependencies {

		// ...
		// other dependencies...
		// ...

		runtime 'org.springframework.security:spring-security-core:3.0.2.RELEASE' // http -> https redirecting
		runtime 'org.springframework.security:spring-security-web:3.0.2.RELEASE' // http -> https redirecting
	}
}

You’ll need to add a Servlet Filter to web.xml now. There are a couple of ways to do this in Grails, namely writing a plugin that can modify web.xml dynamically, or installing the Grails templates into your app and manually editing web.xml. I had planned on doing the first option (writing a plugin), but it was overkill for this, so I decided against it. I’m glad I did. Installing the Grails templates and modifying web.xml manually is painless.

Run grails install-templates from the root of your Grails project to install the web.xml template (along with a few others). Next, edit src/templates/war/web.xml and add the filter definition and mapping in the appropriate places:

<!-- START: use SSL on secure pages -->
<filter>
	<filter-name>channelProcessingFilter</filter-name>
	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<!-- END: use SSL on secure pages -->

<!-- ... other filter definitions ... -->

<!-- START: use SSL on secure pages -->
<filter-mapping>
	<filter-name>channelProcessingFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- END: use SSL on secure pages -->

Make sure that the filter-mapping is the first filter-mapping defined in web.xml (above charEncodingFilter and sitemesh).

Now to actually define the filter. Define it as a Spring managed bean in grails-app/conf/spring/resources.groovy:

import org.springframework.security.web.util.AntUrlPathMatcher
import org.springframework.security.web.access.intercept.DefaultFilterInvocationSecurityMetadataSource
import org.springframework.security.web.access.channel.SecureChannelProcessor
import org.springframework.security.web.access.channel.InsecureChannelProcessor
import org.springframework.security.web.access.channel.ChannelProcessingFilter
import org.springframework.security.web.access.channel.ChannelDecisionManagerImpl

beans = {

	// -------------------------------------------------------------------------
	// -------------------------------------------------------------------------
	// SPRING SECURITY (CHANNEL SECURITY)
	channelDecisionManager(ChannelDecisionManagerImpl) {
		channelProcessors = [new SecureChannelProcessor(),
							new InsecureChannelProcessor()]
	}
	securityMetadataSource(DefaultFilterInvocationSecurityMetadataSource,
							new AntUrlPathMatcher(),
							ChannelConfig.getChannelConfig()) {
		stripQueryStringFromUrls = true
	}
	channelProcessingFilter(ChannelProcessingFilter) {
		channelDecisionManager = ref("channelDecisionManager")
		securityMetadataSource = ref("securityMetadataSource")
	}

}

channelProcessingFilter is the filter referenced in web.xml. It will use the channelDecisionManager to decide if the current protocol (http or https) needs to be switched to the other. And how does channelProcessingFilter know which URLs require which protocol? securityMetadataSource, of course. By default, ports 80 and 8080 are considered insecure, and 443 and 8443 are considered secure. This means that the defaults should work for both development (8080 and 8443) and production (80 and 443). If you’re curious as to the specifics of what these beans do, check their Javadocs.

Configure which URLs require which protocol

See that call above to ChannelConfig.getChannelConfig()? That’s where the configuration for URLs is stored. Create grails-app/conf/ChannelConfig.groovy:

import org.springframework.security.access.ConfigAttribute
import org.springframework.security.access.SecurityConfig
import org.springframework.security.web.access.intercept.RequestKey

class ChannelConfig {

	private ChannelConfig() {} // prevent instantiation

	static def getChannelConfig() {
		LinkedHashMap<RequestKey,java.util.Collection<ConfigAttribute>> requestMap = new LinkedHashMap<RequestKey, Collection<ConfigAttribute>>()

		// resources that can be served over http or https (typically whatever the containing page is served as)
		requestMap.put new RequestKey("/images/**"), [new SecurityConfig("ANY_CHANNEL")]
		requestMap.put new RequestKey("/css/**"), [new SecurityConfig("ANY_CHANNEL")]
		requestMap.put new RequestKey("/js/**"), [new SecurityConfig("ANY_CHANNEL")]
		requestMap.put new RequestKey("/favicon.ico"), [new SecurityConfig("ANY_CHANNEL")]

		// resources that must be served over https
		requestMap.put new RequestKey("/signup"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]
		requestMap.put new RequestKey("/auth/**"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]
		requestMap.put new RequestKey("/admin/**"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]
		requestMap.put new RequestKey("/app/account/edituser"), [new SecurityConfig("REQUIRES_SECURE_CHANNEL")]

		// resources that must be served over http (basically everything else not already listed above)
		requestMap.put new RequestKey("/**"), [new SecurityConfig("REQUIRES_INSECURE_CHANNEL")] // all other pages should be served over http

		requestMap
	}
}

What’s happening here? First, there’s some horrible nastiness with the definition of the requestMap variable (gotta love generics). This is how your configuration is stored and the format securityMetadataSource expects. Each call to requestMap.put() specifies a URL or URL pattern (Apache Ant pattern style) and its corresponding channel security (i.e. http or https).

There are three options for channel security:

• ANY_CHANNEL – Serve the resource with either http or https – it doesn’t matter. This is good for images, CSS, and JavaScript, which should be served using the same protocol as the containing page.
• REQUIRES_SECURE_CHANNEL – Serve the resource using https. This is what will automatically redirect the user to https when needed.
• REQUIRES_INSECURE_CHANNEL – Serve the resource using http. You don’t want to serve your entire site over https, right?

In the configuration above, I first specified all the resources that are protocol agnostic – images, CSS, etc. Then in the next section I specified all of the resources that must be served securely. Finally, the /** specifies that anything else not already listed above will be served over plain http.

Note that order matters (hence the use of a LinkedHashMap that retains insertion order). Rules should be added from most specific to least specific. For example, if the /** rule was at the very top, it would match every resource request, which would be very bad.

If you want to see the debug output from Spring Security as it makes its decisions about whether or not a resource is being served over the right protocol, add the following to your Log4j config in grails-app/conf/Config.groovy:

log4j = {

	// ...
	// ... other logging definitions
	// ...
	debug 'org.springframework.security'

}

Testing

Since you’re testing your app with https, make sure to start Grails with the -https option:

grails run-app -https

This will automatically set up a fake SSL certificate for your app and run https on port 8443.

You should now be able to go to http://localhost:8080 and see that it is indeed served over http. If you have a sign up page like configured above, navigating to http://localhost:8080 should automatically redirect your browser to https://localhost:8443. Clicking on a link to https://localhost:8443/index should then automatically take you back to http://localhost:8080/index. You’ll also notice that resources like images, CSS, and JavaScript are served using whatever protocol the containing page uses.

Caveats

Did you know that if an HttpSession is created over an https connection that it won’t be available to the user when they go back to regular old http? This means that if you have your user log in using https, when they are redirected back to http, their session will be gone. This won’t be a problem for you if you plan to have users always use https once they’ve logged in. But some sites (flickr, for example) prefer to serve most of their pages using http for performance reasons once the user has logged in securely. There is a trick to allow https -> http session migration, but that’s a topic for a later blog post.

With regard to my previous post, it looks like I pulled the Maven command from an old set of documentation. I believe the preferred way to create a new Grails app with Maven is a command like the following:

mvn grails:create-app appName

I can’t say I don’t have anything against Maven, because I don’t like it. Personally I’ve had much better luck with Ant, but then I’ve never worked in a highly distributed team environment with lots of dependencies and builds that couldn’t be managed with a simple Ant script.

Let the holy wars continue…

This just cracks me up.Here’s how to create a Grails app using the Grails command line:grails create-app demoAnd here’s how to create the app using the Maven command line:mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:generate -DarchetypeGroupId=org.grails -DarchetypeArtifactId=grails-maven-archetype -DarchetypeVersion=1.1 -DgroupId=example -DartifactId=demo

Alright, no more Groovy posts for a while after this one. In fact, I hadn’t planned on posting about this again, but I thought it was worth mention.

From the last post, we saw the following results for parsing an XML dataset with about 450 simple elements in it 1,000 times:

• Java: ~9 seconds
• Groovy: ~28 seconds (with new results below…)

I decided to rerun the test for Groovy because of a comment John Wilson left on the first post. He suggested this more concise syntax for the Groovy implementation:

I reran the same benchmark, and I was very, very surprised at the results:

• Java: ~9 seconds
• Groovy: ~28 ~9 seconds

All I can say is wow. I’m not sure what is happening differently, but I’m happy:)

Any ideas what was taking up so much time in the original Groovy implementation?

Following on from the previous post (and here’s the last post), here’s a very quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark I did using the code in the last post.

Date set: a String containing roughly 450 XML elements in the form <contact name=”some name” email=”some email” />

Methodology: I wrote driver programs in both Groovy and Java to run the test. Here’s the one from Java (the Groovy one is similar):

As you can see from the code, very quick and dirty. The test iterates 1,000 times and then prints out the time consumed.

I ran the test several times on my laptop (2Ghz, 2GB ram, blah blah blah it doesn’t really matter here) and here are the general results for total execution time for 1,000 iterations:

• Java: ~9 seconds
• Groovy: ~28 seconds

Quite a difference. I suspect part of that has to do with my inefficiency as a Groovy programmer. Certainly though, you can see that there is measurable difference in performance. I wonder what type of XML parser the Groovy implementation uses behind the scenes. The Java implementation uses SAX. If Groovy were using DOM with XmlSlurper, I could see that making a very large difference. Any experts care to chime in?

Now, before you decide to write off Groovy, another metric of interest might be seconds required to develop the code. It was something like this:

• Java: ~ 1,800 seconds – roughly 30 minutes. (First I had to decide what XML library I was going to use – JDOM? Dom4J? Xstream? Then I had to search and search for documentation on JDOM…and of course I had to download JDOM, well, that is, I have to add JDOM as a dependency in my Maven pom.xml (after I looked up the current version of JDOM at the ibiblio repo), and rebuild my Eclipse classpath with the new JAR on it, and then figure out how to use the JDOM API…) I’ve been writing Java for about 6 years, so I consider myself fairly adept.
• Groovy: ~300 seconds – roughly 5 minutes. (I had to find the page on the Groovy wiki that explained how to process XML.) I’ve been writing Groovy for less than 2 weeks.

So there you have it, my quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark.

I’m not one to reserve judgment, so here goes:

• First, this is just one example. Comprehensively measuring performance is a complex thing, and this benchmark doesn’t claim to do that. There is no such thing as saying “Groovy is slow”.
• Second, I’d gladly trade the frustration and time requirement of the Java solution for the easier to read and write Groovy solution. Servers are cheap. I’ll almost always choose to pay the price in $$$ (which I can always get more of) rather than time (which I can never have enough of).

Update: here’s the final post in this series.

I’ve been trying to slowly integrate some Groovy into my normal Java coding. Here’s just one of the reasons why:

Java code:

Groovy code:

Note that this reduction in complexity happens almost everywhere I choose to use Groovy over Java. Of course there are myriad other ways I could have done this in Java (I even tried Xstream but I couldn’t figure part out so I gave up). The point is that the first way I chose to do it in Groovy was natural, expressive, and easy.

Groovy is not going away any time soon. If you’re a Java developer and wish you could move faster, buy the book, read it, and then start integrating Groovy into your daily programming a little at a time. You’ll be happy you did.

And don’t even get me started on Grails…

Update: here are the second and third posts in this series (benchmarks included).