THOMASJO

ActionController::MimeResponds is brilliant

2011-01-12T00:00:00Z

Was a little bit blown away yesterday, by how smart the ActionController::MimeResponds module in Rails ActionPack really is. For the longest time when using respond_with (the younger sibling of respond_to,) I’ve been doing it wrong.

I’ve written code similar to this whenever I’ve needed to override the default behavior:

respond_to :html, :json

# .. other actions omitted for brevity

def create
  @discussion = Discussion.find(params[:discussion_id])
  @entry = @discussion.entries.create(params[:entry])

  respond_with @entry do |format|
    format.html do
      if @entry.new_record?
        render 'discussions/show'
      else
        redirect_to discussion_url(@discussion)
      end
    end
    format.json { render :json => @entry }
  end
end

My assumption was that if I needed to change the default behavior, I had to more or less mimic the behavior of respond_to (not to be confused with the respond_to as seen in the example above) which is to explicitly define behavior for each MIME type response. Well, it turns out that you only need to override that which deviates from the default behavior and the rest will still be handled as per the default. The respond_with block in the previous example can be simplified as follows:

respond_with @entry, :location => discussion_url(@discussion) do |format|
  if @entry.new_record?
    format.html { render 'discussions/show' }
  end
end

The only thing that deviates from the standard behavior, is the fact I want to render a template belonging to another controller and action (the one that initiated the HTTP POST) whenever the new entry wasn’t successfully created. The assumption being it most likely failed validation, and we need to present the validation errors to the user.

Why respond_with hasn’t been better documented in e.g. The Ruby on Rails Guides or in the API documentation is not known to me, but my best guess would be because this is a new feature in Rails 3, nobody has gotten around to it yet. I only found out about this behavior by looking at the source code, but for all I know this might be common knowledge and I’ve simply overlooked it somehow.

Really simple and naïve Ruby plugin framework

2010-12-15T00:00:00Z

I recently found myself writing some Ruby (IronRuby to be specific) at work for Umbraco that needed to generate HTML for different types of content, destined to be displayed in an aside column. There are many ways of doing something like this, but in order to not violate the Open/Closed Principle, I decided to create a very simple and naïve plugin framework that would automagically wire up new content-type handlers. The way I chose to implement this, was to leverage the meta-programming capabilities in Ruby, more specifically the inherited hook.

Say hello to your friendly neighbourhood hooks

One of the most powerful aspects of Ruby, is its meta-programming capabilities; the aspect that allows you to shape the language to fit your needs and requirements – at runtime.

Hooks are perhaps not strictly speaking a meta-programming capability, but they play a very important role in meta-programming. Undoubtedly the most infamous of all the hooks is method_missing. As the name suggest, it’s the hook that allows you to intercept calls to undefined methods.

class Hello
  def method_missing(name, *args)
    "Hello #{name.capitalize}!"
  end
end

hello = Hello.new
puts hello.neighbour  # "Hello Neighbour!"

Respect the hook

To implement the plugin framework, I decided to leverage a seemingly under-appreciated hook found on Class called inherited. Yet again, the name gives it all away – this hook is called whenever the class is implemented (sub-classed.) We can utilise this hook to implement a simple plugin registration system packaged up in a module.

module Plugin
  module ClassMethods
    def repository
      @repository ||= []
    end

    def inherited(klass)
      repository << klass
    end
  end

  def self.included(klass)
    klass.extend ClassMethods  # Somewhat controversial
  end
end

Because we want to add singleton methods to whatever class includes our plugin module, we use a common, albeit slightly controversial technique; leverage another hook – #included – to automagically extend the target class with the our ClassMethods modules.

Let’s build some plugins!

With the Plugin module we have the foundation needed to implement various types of plugins; let’s create a very silly plugin type for displaying various kinds of messages.

# ./lib/message_plugin.rb
require './lib/plugin'

class MessagePlugin
  include Plugin

  def display_output
    raise NotImplementedError.new('OH NOES!')
  end
end

# ./plugins/hello_world.rb
class HelloWorld < MessagePlugin
  def display_output
    puts 'Hello World! :-)'
  end
end

# ./plugins/goodbye_world.rb
class GoodbyeWorld < MessagePlugin
  def display_output
    puts 'Goodbye World... :-('
  end
end

Because we’ve taken advantage of the inherited hook, all that is necessary for plugins of type MessagePlugin to work, is to require the files containing the implementations, e.g. a directory called “plugins.”

dir = './plugins'
$LOAD_PATH.unshift(dir)
Dir[File.join(dir, '*.rb')].each {|file| require File.basename(file) }

Now all that is required for someone to add a new message to our application, is to inherit from MessagePlugin and drop the implementation into the “plugins” folder.

Taking it one step further…

The MessagePlugin is extremely simple – what if we want to pass data to a plugin? Perhaps we only want to pass the data to plugins that can handle that type of data. An easy way of pulling this off, is to query the registered plugins on whether they can handle it.

# ./lib/type_handler_plugin.rb
require './lib/plugin'

class TypeHandlerPlugin
  include Plugin

  def self.for_type(type)
    repository.find {|handler| handler.can_handle? type }
  end
end

# ./plugins/string_handler.rb
class StringHandler < TypeHandlerPlugin
  def self.can_handle?(type)
    type == String
  end

  def display_output(data)
    puts "String: #{data}"
  end
end

# ./plugins/time_handler.rb
class TimeHandler < TypeHandlerPlugin
  def self.can_handle?(type)
    type == Time
  end

  def display_output(data)
    puts "Formatted Time: #{data.strftime '%A, %B %m, %Y'}"
  end
end

The #can_handle?(type) predicate method hands the responsibility over to the plugins, thus requiring no changes to any other class whenever we add a new type and/or type handler to the application. The Open/Closed Principle remains unviolated.

One more thing…

Just for good measure, here is a rather silly test harness for running the various plugins we’ve peeked at – enjoy responsibly!

require './lib/array'
require './lib/message_plugin'
require './lib/type_handler_plugin'

#
# Add plugins folder to LOAD_PATH and subsequently require all plugins.
#
dir = './plugins'
$LOAD_PATH.unshift(dir)
Dir[File.join(dir, '*.rb')].each {|file| require File.basename(file) }

class TestHarness
  def self.run
    run_message_plugin
    run_type_handler_plugin
  end

  private

    def self.run_message_plugin
      message_plugin = MessagePlugin.repository.random.new
      message_plugin.display_output
    end

    def self.run_type_handler_plugin
      random_data = [Time.now, 'Example string.', 1337].random
      type_handler_plugin = TypeHandlerPlugin.for_type(random_data.class)
      unless type_handler_plugin.nil?
        type_handler_plugin = type_handler_plugin.new 
        type_handler_plugin.display_output(random_data)
      end
    end
end

TestHarness.run

Why I love Ruby

2010-12-09T00:00:00Z

I’ve been a fan of the Ruby language since I was first introduced to Ruby on Rails back in 2005. While I was learning both Rails and Ruby, it quickly became apparent that all the awesome-ness of the former would never have been possible without the latter; what makes Rails great is Ruby, and Ruby would almost certainly still be an obscure and under-appreciated language had it not been for Rails. Ruby is a remarkably beautiful language, and I love working with it.

Freedom to hang ourselves

To me, and infinitely more prominent people like David Heinemeier Hansson, Ruby is very much about freedom. Freedom to shape the language to suit our purpose and fulfil our needs. Ruby will likely never feel old or outdated, because we are free to change it, to create our own versions of the language. The killer feature is that we can do this without needing to change the Ruby source and compiling a new version of the language — we can do it from within our own frameworks and applications.

This is the point where many die-hard supporters of statically typed, compiled languages usually stop and go “What? That cannot possibly be safe? How do you guarantee that X does what X usually does?” The answer is that you don’t, but why do you need it to? As long as you don’t fundamentally alter (which I would interject might be correct in some scenarios) built-in types and so on, what is the problem of changing the behaviour to better suit the tasks at hand? Are you really willing to trade freedom for security? Even if that freedom meant you could create beautiful code and focus more solving the tasks at hand, as opposed to having “guaranteed” runtime behaviour, type safety etc? When was the last time static type checking saved your day? As DHH himself said in his keynote at RubyConf 2010 as a response to the oft cited “Just enough rope to hang yourself with” comment; “Should we outlaw rope, just because people can hang themselves with it?”

There are things you can do in Ruby, changes that fundamentally alter how the language itself works, that you probably shouldn’t do, but should the language really prevent you from doing it, or should you learn on your own? Personally, I’m all for the latter — learning through experience.

It’s also about the people

The freedom Ruby provides me with, is the biggest reason I love it as much as I do, but Ruby also has a fantastic community. A community that continues to innovate and develop fantastic services such as Heroku, and projects such as Sinatra. There is a feeling in the Ruby community that everyone is free to innovate and create the next big thing. Sure, there are some bad eggs in the batch and it’s not always just peachy, but it’s still by far the most inspiring and friendly community I’ve ever felt I’ve been a part of.

XMLDSIG in the .NET framework

2009-08-04T00:00:00Z

I was recently given the task on one of my projects at work, to implement a new version of a digital signature solution that we use to get legally binding signatures" from users. As part of the upgrade process, I had to implement support for XMLDSIG.

To my great joy, I discovered that the .NET framework has supported XMLDSIG for years, but I quickly got into problems and all of the documentation I found online, including the official MSDN documentation covering the XMLDSIG support was either lacking or incorrect.

What is XMLDSIG?

Before I get to the code, and the problems I encountered, I’ll briefly explain the concept of XMLDSIG; XMLDSIG is an old standard in Internet years, and is seemingly accepted as the best and easiest way of digitally signing XML documents.

The signature can distributed in three different variants;

Enveloped signature — the signature is added to the document that was signed.
Enveloping signature — the signature contains the document that was signed.
Detached signature — the signature is distributed separate from the document that was signed.

The differences are rather subtle, but there are many transformations that can be applied to the document prior to signing, and only the right combinations provide valid signatures, and that is one of the problems I encountered with the problematic MSDN documentation.

Enveloping != Enveloped

The problem with the MSDN documentation, and virtually every other example of doing XMLDSIG in .NET, is that they are only based around the “enveloped signature” variant, even when they tell you they are showing you an example of the “enveloping signature” variant. Either the authors of the examples have misunderstood the XMLDSIG specification, or have mistakenly used the word “enveloping”, when they should have used “enveloped.”

The problem is that, most, if not all, of the authors tell you they are showing you an example of the enveloping variant, they are instead using some freakish hybrid variant, and the only reason the sample actually works, is because they are combining the enveloped and enveloping variants. Any attempt to validate the signature without the context of the parent document, will fail.

One approach for generating valid enveloping signatures, is to utilize a different transform that is designed to work with the enveloping variant. The transform I ended up using was the Exclusive XML Canonicalization transform, as it lends itself very well to extracting the enveloped document and using it in another context.

public static class XmlDsig
{
    private const LoadOptions SafeLoadOptions = LoadOptions.PreserveWhitespace;
    private const SaveOptions SafeSaveOptions = SaveOptions.DisableFormatting;


    public static XDocument SignDocument(XDocument originalDocument,
                                         X509Certificate2 certificate)
    {
        if (originalDocument.Root == null) {
            throw new ArgumentException(
                "Invalid XML document; no root element found.", "originalDocument");
        }

        SignedXml signature = GetSignature(originalDocument, certificate);
        XDocument signatureDocument = GetSignedDocument(signature);

        VerifySignature(signatureDocument, certificate);

        return signatureDocument;
    }


    private static SignedXml GetSignature(XNode originalDocument,
                                          X509Certificate2 certificate)
    {
        XmlDocument document = GetXmlDocument(originalDocument);
        if (document.DocumentElement == null) {
            throw new InvalidOperationException(
                "Invalid XML document; no root element found.");
        }

        var signedXml = new SignedXml(document);
        var dataObject = new DataObject("message", "", "", document.DocumentElement);

        signedXml.AddReference(GetSignatureReference());
        signedXml.AddObject(dataObject);
        signedXml.SigningKey = certificate.PrivateKey;
        signedXml.KeyInfo = GetCertificateKeyInfo(certificate);
        signedXml.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;
        signedXml.ComputeSignature();

        return signedXml;
    }


    private static XmlDocument GetXmlDocument(XNode originalDocument)
    {
        var document = new XmlDocument { PreserveWhitespace = true };
        document.LoadXml(originalDocument.ToString(SafeSaveOptions));

        return document;
    }


    private static Reference GetSignatureReference()
    {
        var signatureReference = new Reference("#message");
        signatureReference.AddTransform(new XmlDsigExcC14NTransform());

        return signatureReference;
    }


    private static KeyInfo GetCertificateKeyInfo(X509Certificate certificate)
    {
        var certificateKeyInfo = new KeyInfo();
        certificateKeyInfo.AddClause(new KeyInfoX509Data(certificate));

        return certificateKeyInfo;
    }


    private static XDocument GetSignedDocument(SignedXml signedXml)
    {
        string signatureXml = signedXml.GetXml().OuterXml;
        XDocument signedDocument = XDocument.Parse(signatureXml, SafeLoadOptions);

        return signedDocument;
    }


    private static void VerifySignature(XNode signedDocument,
                                        X509Certificate2 certificate)
    {
        var document = new XmlDocument { PreserveWhitespace = true };
        document.LoadXml(signedDocument.ToString(SafeSaveOptions));
        if (document.DocumentElement == null) {
            throw new InvalidOperationException(
                "Invalid XML document; no root element found.");
        }

        var signedXml = new SignedXml(document);
        signedXml.LoadXml(document.DocumentElement);
        if (!signedXml.CheckSignature(certificate, true)) {
            throw new InvalidOperationException("Signature is invalid.");
        }
    }
}

I had to make another little adjustment to get everything to work correctly, and that was explicitly setting the canonicalization method. Changing the transform, also solved another problem I encountered; the inability to reference the object elements by URI ID, as the default behavior when using the enveloped variant is to look for elements matching the URI ID within the document being signed, instead of within the signature.

But what if I want to use the “enveloped signature” variant?

If you don’t want the variant I needed (enveloping), then changing the code sample above to produce signatures of the enveloped kind, is trivial; first make sure to remove the following two lines:

signedXml.AddObject(dataObject);
signedXml.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;

The next step is to change the GetSignatureReference method; we need to replace the transform implementation with something that is suitable for the enveloped signature.

private static Reference GetSignatureReference()
{
    var signatureReference = new Reference();
    signatureReference.AddTransform(new XmlDsigEnvelopedSignatureTransform());

    return signatureReference;
}

We also need to add an extra argument to the GetSignedDocument method, so that we can pass in the original document.

private static XDocument GetSignedDocument(XNode originalDocument, SignedXml signedXml)
{
    string signatureXml = signedXml.GetXml().OuterXml;
    XElement signatureElement = XElement.Parse(signatureXml, SafeLoadOptions);
    XDocument signedDocument = XDocument.Load(
        originalDocument.CreateReader(),
        SafeLoadOptions);
    if (signedDocument.Root == null) {
        throw new InvalidOperationException("Invalid XML document; no root element found.");
    }

    signedDocument.Root.Add(signatureElement);

    return signedDocument;
}

If you spot any errors, please let me know, so that there can exist at least one correct example of using XMLDSIG in the .NET framework.