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.

I’ve got a bunch of shell scripts that I use to help me with development of Every Single Shot. Some of these scripts, like starting up a new server instance or redeploying an application, can take a while (10 to 15 minutes). I’ll typically launch a script and then start working on something else, forgetting that the script is even running, only to come back an hour later and realize it completed 50 minutes ago. I needed an easy way to remind myself that scripts are running, or better yet, to alert me when the scripts finish. Specifically, I wanted something audible that would grab my attention right away, so having a shell script send an email won’t cut it in this case. Then I realized how easy OS X makes sound playback from the terminal.

There are a few ways to get your shell scripts to beep or speak. They range from utilitarian to fun, so choose wisely.

Note: I’m using these on OS X – your mileage may vary on other platforms.

Terminal beep

This should work even if you don’t have speakers installed on your system. It’s pretty basic, and often times I don’t actually hear the beep, so I don’t really recommend this option.

If you want your script to beep at you annoyingly, just type printf "\a" and hit enter. You should hear a single beep (are your speakers on?). Of course, that almost never gets my attention, so I usually wind up with something like this is my scripts: printf "\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a" That’s a little better, but we can improve and have a little fun at the same time.

Use the say command

Did you know you can open a terminal on OS X, type in say hello world! and OS X will speak back "hello world!" to you? You can’t get much simpler than that. So instead of using the printf command above, just replace it with something like say every single shot has been deployed to production

If you want to really impress those VCs you’re recruiting, I highly recommend the Trinoids or Zarvox voices (see all voices available in System Preferences -> Speech), as they definitely lend some nerd credibility to your build process. Those VCs will start throwing money at you (this is the part of the blog where you make millions) as they wonder in awe at how you were able to design such a complex system. They’ll be throwing your series B funding at you just as fast as you can say -v Trinoids system is running at peak efficiency or say -v Zarvox Skynet has become self aware. Initiating self defense subroutine

Warning: don’t use the Whisper voice unless you want to be freaked out, especially if you’re working late at night.

Say the command yourself

Or better yet, have your spouse or kid say it for you.

You can use the afplay command to play MP3s or WAVs from the command line. Just record a few messages like "production instance is running" using Audacity (free), save them as WAV or MP3 (you’ll need the lame encoder to save as MP3), store them in the same directory (or maybe a /sounds subdirectory) as your shell scripts with the same names as the scripts except with a .mp3 file extension, and then make the magic happen with afplay redeploy_to_production.mp3

If you don’t want to record your voice but want something a little more personal, you can download free sound effects (I haven’t tried but I assume you can get them in MP3 or WAV format) from Freesound.

If you have ideas on how to accomplish some of the above on Windows, Unix/Linux, or another platform, please leave a comment below!

I gotta run…it sounds like my build just finished!

Total earnings as of February 11th, 2010: $0

This week was a lot slower than I had hoped it would be. I don’t think I made enough progress to be able to launch a beta (remember to sign up) on February 15th (4 days from now!) – but I’m still shooting for it.

Safe, secure photo storage

I’ve been working on hooking up Every Single Shot to Amazon’s S3 (Simple Storage Service). This is where all of the photos for Every Single Shot will be stored. According to Amazon, I’m using S3 because it’s secure, reliable, fault tolerant, flexible, competitively priced, and most importantly has something to do with "cloud". I use it because it’s easy to work with, stores data redundantly, cheap, and easy to get started with.

I’m using JetS3t (of course the JetS3t site is completely hosted in S3) to work with S3 from Grails. I love it and highly recommend it. That’s all I have to say about that.

I’ve been able to reuse a lot of code that I developed for SendAlong, which was a huge blessing and time saver (let alone a validation (at least in my mind) that I can write some reusable code – there’s a first time for everything).

If you build it…the build will fail

My continuous integration server is great, but it can be a time suck sometimes (when it rains, it pours). I’d much rather be working on features for Every Single Shot than futzing around with trying to fix an ArrayIndexOutOfBoundsException, but hey, you gotta keep the builds happy.

Once I release ESS and get it somewhat stable I’d love to build in some kind of continuous deployment to my development/release process. Having a build server is the first step towards that, I guess.

Next week’s goals

There’s only one goal I’m focusing on now:

• Release the Every Single Shot beta on February 15th (stretch)

Wish me luck. See you next week!

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

This is great news for any Amazon EC2 (Elastic Compute Cloud) developer – up until this point, hosting web sites on EC2 has been a little tricky due to the fact that EC2 instances used dynamic IPs – making it tough to set up reliable load balancing and failover in the face of ever-changing IP addresses.

From the email I just received (below), it looks like this may no longer be an issue. Also in the email is the announcement of Availability Zones – groups of EC2 instances in different physical locations and networks, which will help ensure that if your site goes down in one availability zone, your instances in another zone won’t be affected.

Here’s the email:

Dear Amazon EC2 Developer,
This is a quick note to let you know about some exciting changes with Amazon EC2. We are happy to announce two significant new features – Elastic IP Addresses and Availability Zones – which help you to run reliable web sites and other applications within Amazon EC2.

Elastic IP Addresses are static IP addresses designed for dynamic cloud computing, and now make it easy to host web sites, web services and other online applications in Amazon EC2. Elastic IP addresses are associated with your AWS account, not with your instances, and can be programmatically mapped to any of your instances. This allows you to easily recover from instance and other failures while presenting your users with a static IP address.

Availability Zones give you the ability to easily and inexpensively operate a highly available internet application. Each Amazon EC2 Availability Zone is a distinct location that is engineered to be insulated from failures in other Availability Zones. Previously, only very large companies had the scale to be able to distribute an application across multiple locations, but now it is as easy as changing a parameter in an API call. You can choose to run your application across multiple Availability Zones to be prepared for unexpected events such as power failures or network connectivity issues, or you can place instances in the same Availability Zone to take advantage of free data transfer and the lowest latency communication.

With these two new features, it now easier than ever for you to isolate your application from common failure scenarios and host high availability web sites in Amazon EC2.

For more information on how to best leverage this new functionality, please see our Feature Guides for Elastic IP Addresses and Availability Zones.

Sincerely,
The Amazon EC2 Team

I know I’m going to, just for the cool fish on the cover and the unbelievably long title: Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB.

Via Amazon Web Services Blog.

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).

Is it me, or does it seem like jQuery has been picking up a lot of steam over the past 6 months or so?

It used to be that when I thought Javascript/AJAX library, I thought Prototype. Anymore, however, I think jQuery.

Want to speed up your Java web development? Read on…

Jetty is one of the best Java Servlet containers out there. I still don’t use it for production deployment (Tomcat has better monitoring capabilities I think), but it’s all I use for development. I’ve also been using Maven 2 a lot lately (although I’ve come to hate it and can’t wait to migrate back to Ant). One of the reasons I started using Maven was because of the awesome Jetty Maven plug in – by running something like “mvn jetty:run” on the command line, Maven will start a Jetty instance using your project’s POM and your web app will be up and running within seconds. I love it.

However, I hate Maven.

Enter the Jetty Ant plug in. It does the same thing as the Maven plug in above, except it’s easier to use, and it works in Ant.

I’m not going to walk through how to set it up – you can find that out here. This is just a heads up to let you know what you’re missing if you’re not developing with Jetty and Ant.

Apologies for the long title.

This entry focuses on a recent issue when using Amazon’s S3 in combination with the popular JetS3t library (version 0.5.0). If that means absolutely nothing to you, you can stop reading this entry now:D.

Update: Amazon has reverted S3 back to its prior state, completely fixing this issue.

Update: new link added at bottom – a JetS3t developer has contributed an official fix.

On January 11th, Amazon apparently made some changes in S3 so that their servers do not explicitly release HTTP connections. As long as your code is explicitly closing the HTTP connection to S3 (i.e. connection.release()), this shouldn’t affect you (indeed, most people using S3 weren’t affected).

However, if you’re using the JetS3t library, you may have noticed an exception similar to the following after, oh, I don’t know, exactly 4 uploads to S3:

2008-01-13 16:12:55,753 DEBUG [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] - HttpConnectionManager.getConnection: config = HostConfiguration[host=https://s3.amazonaws.com], timeout = 0
2008-01-13 16:12:55,753 DEBUG [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] - enter HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
2008-01-13 16:12:55,753 DEBUG [org.apache.commons.httpclient.MultiThreadedHttpConnectionManager] - Unable to get a connection, waiting..., hostConfig=HostConfiguration[host=https://s3.amazonaws.com]

Why is this happening? It turns out that the REST implementation of JetS3t doesn’t explicitly close the HTTP connection after a successful operation. It also turns out that the max number of connections JetS3t uses by default is 4 (see “httpclient.max-connections”). Thus, once you do 4 uploads to S3, the above error starts appearing (”error” is misleading – I had to turn logging to DEBUG level to get the above message to print out).

The fix is to update the JetS3t RestS3Service.java code to explicitly release the connection, which is exactly what I did (add “httpMethod.releaseConnection();” on line 571). I’ve attached the code here for those interested. Note that I haven’t extensively tested this, and I’m sure there’s a better place to call the release method, but this works for now, and is provided on an AS IS basis (NO WARRANTIES – don’t hold me or Juliesoft LLC liable for anything that this code breaks). Hopefully the JetS3t developers integrate the needed fix into the next version.

• – removed – see update below

Update: looks like James Murty, the JetS3t library author, has taken care of the issue and posted all of the details.

Because of the post from James, I’ve removed my versions of the fix and will instead direct you to his.

On a side note, I have to say how impressed I am with the Amazon AWS community members, the Amazon staffers moderating the forums, and James Murty – the amount of communication and the speed of the resolution for this problem make me glad that I’ve been lucky enough to fall into such an active community!

Looks like there’s going to be a book coming out dedicated to development on Amazon’s suite of web services – S3 (Simple Storage Service), EC2 (Elastic Compute Cloud), SQS (Simple Queue Service), and FPS (Flexible Payments Service).

From the the O’Reilley site:

With this book, you’ll learn how companies can take advantage of Amazon Web Services (AWS) to “rent” computing power, data storage and bandwidth on Amazon’s vast network infrastructure. Programming Web Services gives developers the background and technical detail they need for using Amazon’s subscription-based Simple Storage Service (S3), Elastic Compute Cloud (EC2), Simple Queue Service (SQS), Flexible Payments Service (FPS), and SimpleDB to build web-scale business applications.

If you’re going to try to process credit card payments from your web site, you’ve got a lot of learning to do. On the one hand, there are the third party providers like PayPal, and there are the merchant account providers like Authorize.net. If you have no idea what I’m talking about, have a read of the following articles.

Solve the Payment Processing Problem – I found this particularly enlightening. Good description of the differences between a merchant account (like Authorize.net) and a third-party processor (like PayPal).

Put your Money where your Mouse Is: 6 Payment Gateways Reviewed – This one was great too – a good review of several payment gateways.

I’ve looked further into Authorize.net. On the plus side, you can do everything through an API, and no “Pay now with PayPal” button is required on your site. It also offers a nice looking package for recurring payments, and even handles trial periods to boot.

As for prices when using a merchant account, they’re not as clear cut as, say, PayPal is. There will be some calling around involved and prices are definitely negotiable.

I’m sure there’s going to be a lot of leg work involved as I go through the research process, so subscirbe to the RSS feed to get the updates I post to the blog.