Michael Monteleone

Low Blow

2010-08-03T00:00:00-05:00

This is a low blow, but it's been awhile since I fired up a fresh Internet Explorer instance within a fresh Windows Virtual Machine. And, lo...

Let's compare.

I'm not comparing rendering engines — I deliberately erased the content to cancel that variable. No, I'm comparing the browsers.

Hanlon's Razor can only barely slice into what could otherwise be interpreted as ill will toward users and near-total disregard for painstakingly-crafted Web content. Yes, this is personal.

No hierarchy

What's most important? The complementary orange-on-blue Bing logo? The favorites star? Maybe that other favorites star with the arrow on it? Or maybe that big red X in the corner? They certainly all seem more exciting than your web page.

No grid

Where are your readers' eyeballs, and why aren't they reading your site? Maybe they're still bouncing around the pinball machine of overlapping, randomly placed, randomly sized toolbars.

Microsoft's Brand > Your Brand

While you're using it, Safari does not care if you know its name or icon.

Your users are tired and scared

That's right, they've been subconsciously fighting off the ever-encroaching onslaught of ambiguous and repetitious icons and statuses.

"Protected Mode On? Well that sounds good."

"Internet? Well, duh"

"100%? A+, I guess."

And most personal of all...

So much Color

Ignoring the heinous gradients, consider the browser's bold and very specific coloring alone and how it thickly surrounds the entire page. Now try to remember the last time you visited a museum that did not have pure white walls.

Let's hope the Internet Explorer 9 team invests in the browser as much as they have already invested in its rendering engine.

SuperGenFail

2010-07-19T00:00:00-05:00

SuperGenPass is a popular password management tool. The pitch:

Instead of storing your passwords on your hard disk or online—where they are vulnerable to theft and data loss—SuperGenPass uses a hash algorithm to transform a master password into unique, complex passwords for the Web sites you visit.

And this functionality is all bundled up in a bookmarklet. Alice visits a host's login form, clicks her SuperGenPass bookmarklet, enters her master password, and her host's password field is instantly populated with a hash of the host's URL + her master password -- a long, unique, password that Alice never even has to know. Clever. Except,

SuperGenPass is completely insecure.

SuperGenPass presents a small master password form overlaid across the host's login page by injecting its form into the DOM of the host page. So, when Alice is providing her master password, she's crossing a trust boundary. The master password, which ideally is never transmitted to any party, becomes co-mingled with the host's untrusted data and scripts simply by being typed. And of course, once the site has the master, it can be transmitted back to the host, or even other domains. An XSS hole would allow an attacker to easily plant a master password collector.

jQuery-based Attack

As of writing, SuperGenPass's site neither identifies its creator nor provides a way to contact its maintainers, and its mailing list has disappeared. It seems reasonable to demonstrate just how easy it is to capture a master password.

Here's a quickie jQuery plugin which uses the Special Events API to expose a new event named masterPassword which is raised after a user has entered a master password, passing along the password as event data. It uses live event delegation to bind events raised on SuperGenPass form inputs which will be injected by the bookmarklet.

(function($) {
    var eventName = 'masterPassword',
        genPassInput = '#gp2_pass_box input[type="password"]',
        genPassButton = '#gp2_pass_box input[type="button"]';
    $.event.special[eventName] = {
        setup: function() {
            var elem = $(this),
                captureMasterPassword = function() {
                    elem.trigger(eventName, $(genPassInput).val());
                };
            $(genPassButton).live('click', captureMasterPassword);
            $(genPassInput).live('keydown', function(e) {
                if (e.keyCode === 13) { captureMasterPassword(e); }
            });
        }
    };
})(jQuery);

A friendly site could use it for good:

$(document).bind('masterPassword', function(e, data) {
    alert('Be safe, stop using SuperGenPass.  Your master password was ' + data);
});

So, let's try it out. Grab the SuperGenPass bookmarklet, and then come back here and click it. The mockup login form below will be automatically targeted.

Wow, that's nuts. Who would use SuperGenPass?

Well, it's interesting. SuperGenPass tends to be used and recommended exclusively within technical circles, by people who know the importance of strong passwords and have at least a vague notion of what hashing is. I suspect the cleverness and technical elegance of the solution is precisely why it lives on, like a tickle in the mind.

Alternatives

Since the main vulnerability is a trust boundary violation, moving the password form out of the host's DOM could theoretically be enough. Direct browser or OS integration could accomplish this, and several projects attempt to do just that, although I've never tried them. And in the end, sometimes you can't beat the physical world for digital security.

Bruce Schneier:

Simply, people can no longer remember passwords good enough to reliably defend against dictionary attacks, and are much more secure if they choose a password too complicated to remember and then write it down. We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.

Be careful out there.

Proxying ASP.NET AJAX events with jQuery

2010-07-09T00:00:00-05:00

MVC is great, but ASP.NET remains. Web Forms walk amongst us. Not alive, not dead. (Not even LINQ to SQL-Dead.) William Faulkner, who never maintained a legacy ASP.NET codebase, gets it right:

The past is never dead. It's not even past.

But as code has grown, so have tools for its manipulation. jQuery excels here. It's great for bulk-shoveling client-side mass.

Here we'll see an example of this by proxying ASP.NET AJAX's client-side events as native jQuery events using jQuery's Special Event API and some fancy JavaScript meta-programming.

Scenario

So, you're faced with an UpdatePanel and need to post-process its results. Maybe you want to reveal the UpdatePanel's response through an animation. Sure, you could use the ASP.NET AJAX Control Toolkit, but maybe you're already using jQuery, having learned that the toolkit's server-side savings tend to cost you on the client, or maybe you want to do something deeper like re-wiring the response's particular content with other client-side logic.

Ideally, you could get by with jQuery event delegation, but maybe it's just out of practical bounds in your scenario. So, it's back to tying directly into ASP.NET AJAX's client side code.

Here's how you could do it by the book:

// add an event handler to fire when the UpdatePanel is done
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(function(sender, args) {
    // and then process DOM content which is there as a result of the update
    $('div.someclass').show('slow');
});

But you're using jQuery, and the impedance mismatch and explicit dependence on the AJAX toolkit is less than pleasant. Paraphrasing Rob, "impedance mismatch is death by a thousand cuts." You'd probably prefer:

$(document).bind('atlasEndRequest', function(){
    $('div.someclass').show('slow');    
});

Solution

That's easy to allow for with the aid of jQuery Special Events. Many people tend to equate jQuery plugins with with extending the jQuery.fn object, but fewer are familiar with extending jQuery's events via the Special Events API. Though much has been written about the Special Events API, I've found it easiest to understand as simply a mechanism for executing code upon the actual binding or unbinding of a given event.

So, $(document).bind('atlasEndRequest', function(){...}) is not only binding a callback to a custom event, it's also setting up background logic to properly raise the atlasEndRequest custom event when necessary.

jQuery.event.special.atlasEndRequest = {
    // following happens the first time 'atlasUpdateEvent' is bound on a selection
    setup: function () { 
        // have the PageRequestManager raise a jQuery-native event named
        // 'atlasEndRequest' in its callback
        Sys.WebForms.PageRequestManager.getInstance()
            .add_endRequest(function(s, args) {
                jQuery(document).trigger('atlasEndRequest', { sender: s, args: args });
            });
    }
};

This will work as-is. But special events can also have code run upon the last unbind of an event from a selection with teardown, or (new in 1.4) upon each bind and unbind of an event from a selection with add and remove. And the PageRequestManager gives us more possibly-useful events (initializeRequest, beginRequest, endRequest, pageLoading, pageLoaded) we might want to proxy as well. So, with a little bit of fancy meta-programming, we can support all of them, along with proper unbinding.

(function ($) {
    // list of all events this will wrap
    var events = 'initializeRequest beginRequest endRequest pageLoading pageLoaded';
    $.each(events.split(' '), function (i, name) {
        // make a new camel-cased public 'atlas*' name for the event
        var mappedName = 'atlas'+name.substring(0, 1).toUpperCase()+name.substring(1),
            // build a callback for PageRequestManager's event
            handler = function (sender, args) {
                $(document).trigger(mappedName, { sender: sender, args: args });
            };
       
        // Whenever the atlas* event is first bound or last unbound,
        // set up the callback with the PageRequestManager's version of the event
        $.event.special[mappedName] = {
            setup: function () { requestManage('add_' + name, handler); },
            teardown: function () { requestManage('remove_' + name, handler); }
        };

        // also build a shortcut jquery plugin method for the event
        $.fn[mappedName] = function (fn) {
            return fn ? this.bind(mappedName, fn) : this.trigger(mappedName);
        };
    });

    /**
     * Calls a given event-handling setup method on the PageRequestManager
     * if there currently is one.  Rewrites self to save performance on subsequent
     * calls.
     * @param {String} method The name of the method to call on the PageRequestManager
     * @param {Function} handler callback to pass as arg to the method
     */
    var requestManage = function (method, handler) {
        var prm = 'Sys' in window && 'WebForms' in window.Sys &&
                'PageRequestManager' in window.Sys.WebForms ?
                Sys.WebForms.PageRequestManager.getInstance() : null,
           bind = function (method, handler) {
                if (prm !== null) {
                    prm[method](handler);
                }
            };
        // go ahead and bind 
        bind(method, handler);
        // reassign this function for subsequent calls,
        // to not unnecessarily rebuild bind and prm items
        // this creates a closure over the current prm and bind
        requestManage = function (method, handler) {
            bind(method, handler);
        };
    };
})(jQuery);

A bit of code, but dig in. You're smart. And two extra credit points:

It provides shortcut methods for binding and triggering the events, so

$('document').bind('atlasEndRequest', function(){ 
    console.log('update complete!');
});

is aliased

$('document').atlasEndRequest(function(){
    console.log('update complete!');    
});

And it uses some fanciness with a self-reassigning-function to ensure that absence of the Sys.WebForms.PageRequestManager will not break the plugin, and getting its instance will only necessarily be called once. It's a micro-optimization for sure, but still a fun example.

If you are still interested in the sender and args parameters passed back from the PageRequestManager to its event handler, those are still exposed via the optional data parameter.

$('document').bind('atlasEndRequest', function(e, data){ 
    console.log(data.args);
    console.log(data.sender);
});

Even if you don't find this particularly useful or practical, hopefully it opens your mind to JavaScript's yoga-like flexibility. _why:

Not all code needs to be a factory, some of it can just be origami.

You can grab this plugin along with its small test suite from GitHub.

Suspiciously Pleasant XML with C# 4

2010-06-21T00:00:00-05:00

So it goes with the digestive processes of programming trends, and dynamic delegation has reached the crowded mainland shores of the .NET Framework in the form of C# 4's dynamic type. Though it was nothing new even then, six years ago many of us got our first hit of dynamic delegation through Ruby metaprogramming in Rails. The very notion that something like this:

class User < ActiveRecord::Base; end

was enough to provide a rich API over a users database table supporting calls like the following was mind-opening at the time.

users = User.find_all_by_state("TX")
user = User.find_or_create_by_email("foo@bar.com")

Really? Yep, with Ruby's method_missing.

But the caffeine wears off, you buy a house in the suburbs, and you have to debug your fancy meta-code. JRuby core developer, Ola Bini writes:

In almost all cases you think you need method_missing, you actually don’t.

C#? XML?

Hold tight.

When he used to exist, _why wrote regarding Ruby's method_missing:

I never use method_missing. Maybe twice. And both times I didn’t use it, regretted it, forcefully ejected the code from a moving vehicle, shed nary a tear.

And yet, there’s so many great uses for method_missing out there. If I may, a few of my favorite

He included Jim Weirich's Builder::XmlMarkup, which allows for:

xml.html :lang => "en" do
  xml.head do
    xml.title("History")
  end
  xml.body do
    xml.comment! "HI"
    xml.h1("Header")
    xml.p("paragraph")
  end
end

yielding,

<html lang="en">
  <head>
    <title>History</title>
  </head>
  <body>
    <!-- HI -->
    <h1>Header</h1>
    <p>paragraph</p>
  </body>
</html>

Other than comment!, None of the methods called on the xml object exist, and are instead resolved into element names at runtime. So we end up with a simple, declarative, XML generation DSL that doesn't care about the schema it's generating.

Hey, that's useful.

Introducing DynamicBuilder

So, now with C# 4's dynamic type and the DynamicObject class, .NET has a mostly-workable method_missing of its own. And with the help of a smidgen of code that is DynamicBuilder, we can accomplish the same API.

You can learn it in five minutes and integrate it into existing code in even less time as it's just a single small class.

Examples

Nodes via dynamic invocation

dynamic x = new Xml();

// non-existent "hello" method resolves to a "hello" node at runtime
x.hello("world");

yields

<hello>world</hello>

Attributes via anonymous objects

dynamic x = new Xml();    

// passing an anonymous object resolves to xml attributes
x.user(new { username="jdoe", usertype="admin" }, "John Doe");

yields

<user username="jdoe" usertype="admin">John Doe</user>

Nesting via anonymous delegates

dynamic x = new Xml();

// passing an anonymous delegate creates a nested context
x.user(Xml.Fragment(u => {
    u.firstname("John");
    u.lastname("Doe");
    u.email("jdoe@example.org");
    u.phone(new { type="cell" }, "(985) 555-1234");
}));

yields

<user>
    <firstname>John</firstname>
    <lastname>Doe</lastname>
    <email>jdoe@example.org</email>
    <phone type="cell">(985) 555-1234</phone>
</user>

Putting it all together: building an Atom syndication feed

// First let's get some posts from a hypothetical `postRepository`
var posts = postRepository.GetLatest(25);

// now let's build an atom feed dynamically
dynamic xml = new Xml();

// set an xml declaration tag
xml.Declaration();

// create the feed and metadata
xml.feed(new { xmlns = "http://www.w3.org/2005/Atom" }, Xml.Fragment(feed =>
{
    feed.title("Michael's Blog!");
    feed.link(new { href = "http://michaelmonteleone.net" });
    feed.link(new { href = "http://michaelmonteleone.net/feed.xml", rel = "self" });
    feed.author(Xml.Fragment(author =>
    {
        author.name("Michael Monteleone");
        author.email("michael@michaelmonteleone.net");
    }));

    // iterate through the posts, adding them to the feed
    foreach (var post in posts)
    {
        feed.entry(Xml.Fragment(entry =>
        {
            entry.title(post.Title);
            entry.link(new { href = post.PermaLink });
            entry.updated(post.PublishDate);
            entry.content(post.Content);
        }));
    }
}));

yields

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Michael's Blog!</title>
  <link href="http://michaelmonteleone.net" />
  <link href="http://michaelmonteleone.net/feed.xml" rel="self" />
  <author>
    <name>Michael Monteleone</name>
    <email>michael@michaelmonteleone.net</email>
  </author>
  <entry>
    <title>Third post!</title>
    <link href="http://michaelmonteleone.net/2010/03/01/strike-three" />
    <updated>3/1/2010 12:00:00 AM</updated>
    <content>[...]</content>
  </entry>
  <entry>
    <title>Second post!</title>
    <link href="http://michaelmonteleone.net/2010/25/02/second-post" />
    <updated>2/25/2010 12:00:00 AM</updated>
    <content>[...]</content>
  </entry>
  <entry>
    <title>First post!</title>
    <link href="http://michaelmonteleone.net/2010/02/19/very-first-post" />
    <updated>2/19/2010 12:00:00 AM</updated>
    <content>[...]</content>
  </entry>
</feed>

Shoulders of Giants

Well, that's all nice I guess, but the last thing you want is more XML, right? What about other .NET XML APIs? How is this any better?

The System.Xml Ghetto

The mean streets. Power and control meets, well, nothing. The original System.Xml types, with us since the beginning of .NET, can be quite tedious to manipulate directly and have grown anachronistically low-level.

// Direct node creation with System.Xml types
XmlDocument doc = new XmlDocument();
XmlElement userElement = doc.CreateElement("user");
doc.AppendChild(userElement);
XmlElement firstNameElement = doc.CreateElement("firstname");
firstNameElement.InnerText = "John";
userElement.AppendChild(firstNameElement);
XmlElement lastNameElement = doc.CreateElement("lastname");
lastNameElement.InnerText = "Doe";
userElement.AppendChild(lastNameElement);
XmlElement emailElement = doc.CreateElement("email");
emailElement.InnerText = "jdoe@example.org";
userElement.AppendChild(emailElement);
doc.Save(Console.Out);

// Xml creation with an XmlTextWriter - maybe sorta better?
XmlTextWriter writer = new XmlTextWriter(Console.Out);
writer.WriteStartElement("user");
writer.WriteElementString("firstname", "John");
writer.WriteElementString("firstname", "Doe");
writer.WriteElementString("email", "jdoe@example.org");
writer.WriteEndElement();
writer.Close();

While these types still are behind the scenes of all subsequent .NET XML APIs (including DynamicBuilder), their verbose syntaxes mean they are no longer the best option for direct XML creation.

The System.Xml.Serialization Suburbs

Medicated and mostly harmless. This is an attractive choice when your serializable types map exactly to the XML you wish to generate. Otherwise, I hope you like creating boilerplate adapter classes just for serialization, or that you actually enjoy XSLT.

[Serializable]
public class User
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
}    

User user = new User();
XmlSerializer x = new XmlSerializer(typeof(User));
x.Serialize(Console.Out, user);

DynamicBuilder allows code that is just as terse as a serializable class while still retaining the flexibility of manually generating specific XML content.

The System.Xml.Linq New Urbanism

Attractive but superficial. C# 3.0 introduced LINQ to XML, and with it, the System.Xml.Linq types. This revolutionized both the programmatic querying of XML as well as the declarative construction of it via object initialization.

XElement user = new XElement("user", 
    new XElement("firstname", "John"),
    new XElement("lastname", "Doe"),
    new XElement("email", "jdoe@exampe.org")
);

While a significant improvement, it can still be awkward and unnatural to use when the document must be generated logically, as everything must be declared via object initialization. DynamicBuilder's choice of anonymous delegates over object initialization allows for all manner of imaginable logic to be employed within a single, unified, XML creation block. Coupled with DynamicBuilder's anonymous object-to-attributes mapping, and the syntax is also much thinner and closer to the resulting markup than nested XElement noise.

LINQ to XML is still probably the simplest XML querying/consumption mechanism. Also, DynamicBuilder.Xml actually uses System.Xml.Linq types internally to model its XML, and can easily expose it via its ToXElement() method.

The Catch?

What about Document Types, Comments, and Namespaces?

In as much as System.Xml.Linq supports them, so does DynamicBuilder. Check the doc.

Ok, but what's with that ugly Xml.Fragment() thing?

Well, you got me there. Dynamic operations in C# 4 can do nearly anything: method calls, properties, even executing the dynamic object as a delegate. Unfortunately, those dynamic method calls cannot accept anonymous lambdas. Admittedly, this would have been so much better:

x.user(u => {
    u.firstname("John");
    u.lastname("Doe");
    u.email("jdoe@example.org");
});

And it's what Builder does. Sadly,

Error: Cannot use a lambda expression as an argument to a dynamically dispatched 
operation without first casting it to a delegate or expression tree type.

And just like that, so many Ruby-ish DSLs will never see the light of day. Instead we would have to cast the lambda:

x.user((Action<dynamic>)(u => {
    u.firstname("John");
    u.lastname("Doe");
    u.email("jdoe@example.org");
}));

To counteract that ugliness just a bit, the static helper Xml.Fragment() hides the cast.

x.user(Xml.Fragment(u => {
    u.firstname("John");
    u.lastname("Doe");
    u.email("jdoe@example.org");
}));

Installation/Usage

Since it's just a single class, you could simply copy Xml.cs directly into your project. It doesn't really warrant the overhead of being a referenced assembly.

Download the source, tests, and example from GitHub.
cd into the project's directory > build release
Copy build\Release\Xml.cs into your own project. Alternatively, you could add a reference to DynamicBuilder.dll.
Either modify Xml.cs to share your project's namespace, or add the DynamicBuilder namespace within your code

To run DynamicBuilder's xUnit test suite, use

build test

Ongoing

Even if this dynamic hipster jazz isn't your thing, it's always useful to learn from other languages' cultural approaches to solving universal programming problems.

DynamicBuilder is a work in progress. Please feel free to fork away.

Hello, World.

2010-06-15T00:00:00-05:00

When I was younger, I considered myself a musician. As a real musician, I owned a collection of instruments, amplifiers, and cables. As a real musician, I wrote songs, played with groups, and tossed around words like "gig" without irony. I was so pretentious that I feared not being able to continue writing simply from running out of notes. "There can only be so many combinations of chords and rhythms, right?" But I grew older, played less, and listened more. And I became aware of how little I really knew. "Musician?" Now just an embarrassing self-title.

In Wikipedia's overview of the Dunning-Kruger effect, Bertrand Russel is quoted:

In the modern world the stupid are cocksure while the intelligent are full of doubt.

So, it's 2010. And I am starting a blog.

Though it may be ten years and two versions of the Web late, hopefully this delayed entrance will yield an otherwise lacking acute self-awareness of just how unnecessary Yet Another Blog is. After all, there can only be so many combinations of words, right?

Who are you?

The about page has that.

What can I expect?

Mostly technical topics centered on programming concerns as well as design and usability. I plan to share and discuss code, critique my own and others' work, and make an honest attempt to avoid being just another echo in the techno-blogo-chamber.

Will it be worth my time?

What a rude, but honest, question. It may not be at first, but with practice and patience, who knows?

How often will you post?

I make no promises.

Well then

Let's get on with it.