Sunday, January 27, 2013

App Harbor, Security and Configuration

By now we've all read the story about keys and passwords being kept in source control. It seems pretty obvious it's a bad idea but it tends to be our tools that force us down this path. At the moment this is being forced on me by app harbor and it's deployment model.

App Harbor deployment works by taking a web.config and applying the transformations in web.release.config. The problem with this is that all you configuration must be under source control, and everyone that works on the source has access to private security information.


As a general rule, I don't like to keep the Web.config file in source control at all and generally write an ignore rule for it. Having it in source control virtual guarantees that at some point someone will put private information in there accidentally. Nothing is more frustrating than pulling the latest version of the source and having someone overwrite all your settings.

With a traditional CI server setup I would have a config template and would generate a full Web.config based on settings in the CI server but App Harbor is very limited support for this style. This is a nice compromise, it's easy to setup a configuration for a new user or server and it keeps everyone from overwriting each others configuration files.

App Harbor however, forces you to have a Web.config file in source control. Forcing you to be just on blonde moment away from commiting private information.

Configuration Variables

App Harbor provides half a solution, it allows you to set configuration variables in the application manager interface. While this is okay for some simple key value settings, sometimes the configuration is more complex. Here is an example of a configuration section using the OAuth2 library:

      <add clientType="GoogleClient" enabled="true" clientId="" clientSecret="aaaaaaaaaaaaaaaaaaa" scope="" redirectUri="~/User/Auth" />

The only way to get such a configuration into App Harbor is to have it in a config file under source control,  giving everyone access to private information.

What I'd Like

What I'd really like is rather simple. I want to store a config file in the application manager interface that will be copied into the project as part of the build. This way no configuration has to be under source control, no private information shared and simplicity remains.

Friday, January 25, 2013

How to turn away paying customers

I have a couple of recent examples of companies being unwilling to take my money.

The first is Amazon. I was working on an app and thought amazon S3 would be perfect for blob storage. After going through the most annoying, buggy sign up experience possible I was informed that Amazon, the worlds largest online retailer, is unable to process a card with a CCV.

The solution: Rackspace Cloudfiles. Which was actually closer to what I was looking for anyway.

The next one was nDepend. I've wanted this for a while and used the trial at a number of places. I finally decided to cough up and buy a legit copy. The only thing standing in my way is there reluctance to accept gmail accounts. Sorry guys, web mail is ubiquitous and you better get used to it, until then I'll just go without.

Update: As you might have seen in the comments, nDepend has some very pro active support and have enabled purchases with gmail addresses. So, I'm now a proud owner. Fortunately the current project only has one major issue but there are some others where I know nDepend will help out a lot.