Git: Merge vs. Rebase

This is the most concise explanation I’ve found of why git rebase is valuable compared to merge:

How do we keep [a] branch up to date? Merging the newest upstream commits is easy, but you want to avoid creating a merge commit, as that won’t be appreciated when pushed to upstream: you are then effectively re-committing upstream changes, and those upstream commits will get a new hash (as they get a new parent). This is especially important, as those merged commits would be reflected in your Github pull request when you push those updates to your personal github feature branch (even if you do that after you issued the pull request.)

That’s why we need to rebase instead of merging. … Both the rebase option and rebase command to git will keep your tree clean, and avoid having merge commits.

I get it now!  via

Encrypting web.config sections with shared certificate

We deploy a long-lived, self-signed certificate to each node in our web farm for purposes of decrypting sensitive sections of our web.config files. This allows us to encrypt and safely version the web.config transforms for our test and production environments.

This post provides a great walkthrough on how to encrypt/decrypting specific sections of a web.config with that self-signed certificate. The thumbprint of that cert is required and will be versioned, but that’s pretty low-risk.

That post also includes a useful bit about what’s required to encrypt a custom web.config section, which is handy if you want to separate your sensitive data (keys, passwords, etc.) from other non-sensitive appSettings.

WIF-friendly Machine Key Generator

We’ve been using Windows Identity Federation to provide federated authentication for our site, mostly to great success. However, we’ve always had a problem with our load balancing. This post starts to dissect that a problem a little bit.

A bit of background: each federated user gets a cookie that contains all their ‘claims’ (roles, etc.). This cookie gets encrypted by the server that handles the authentication request. Now, each server had its own encryption keys, which means that one server couldn’t read a claims cookie that was encrypted by another server. Thus, we had to keep sending users back to the server they authenticated with, or else all sorts of things go haywire. This doesn’t scale very well, and causes real problems if you have to take a server out of load balancing.

We determined that we could instruct each server to use the same encryption key using the web.config’s system.web/machineKey setting. There was a lot of bad advice on the web about how to do this properly. Worse, IIS wouldn’t tell you that it was ignoring your bad machineKey setting and just creating a new one at runtime.

After a lot of experimentation and gnashing of teeth, we found a machineKey format that makes IIS happy. Here’s some code that’ll do it right. This creates a 512-bit validationKey and 192-bit decryptionKey. (It’s structured as an nUnit test because that makes it easy to copy the resulting <machineKey> to the clipboard.)