Details

The bug revealed two issues in the OpenID for Node.js library: * The unbtwoc routine which converts a received binary two’s complement number was flawed * The computed shared secret was not converted to binary two’s complement form before it was used to compute the signature

These two issues together caused some authentication attempts to be rejected.

And, as always, when writing code and living in the real world you sometimes need to do things that do not quite fit the pattern. In this case, I needed to draw on a canvas from my view model whenever some observables on it changed. The pragmatic thing to do when you need to draw on a canvas is to just grab the canvas by ID or whatever, but since this canvas lived in a template, identifying it through selectors quickly got messy (and hard).

Binding to it seemed like a much better idea, so I created the simple element Knockout.js binding. This is a one-way-to-source binding (.NET guys will be familiar with this terminology), meaning that the binding only writes to the view model from the view. In addition, the binding only does this once (when it is initialized), as the element will stay for the lifespan of the page.

So, in all its glory, here is my Knockout.js element binding:

ko.bindingHandlers.element = {
    init: function(element, valueAccessor) {
      var value = valueAccessor();
      value(element);
    }
};

Use it as you would any other binding:

<canvas width="100" height="60" data-bind="element: yourObservable"></canvas>

Simple as that. Now go use it!

First of all, I want to emphasize that I think both of the aforementioned tools are great efforts, and most certainly provide value to those using them.

Second, the reason for being a passive listener is that I believe debates of this kind are utterly meaningless and provide no value whatsoever; making and improving the tools at hand is what provides value. I will make an exception this time as this debate (among other things) discusses a (if not the) fundamental motivation for writing Continuous Testing for Visual Studio, and highlights one of the significantly differentiating aspects of the approach it takes.

Third, and most importantly, the statement from the Herding Code podcast is objectively true. Put in even clearer words: It is impossible for a Continuous Testing tool to do static analysis and achieve perfect and correct test minimization. Even near perfect test minimization is impossible. The only generally possible thing is simple dependency resolution. Don’t let anyone tell you otherwise.

That is why Continuous Testing for Visual Studio does not do static analysis¹, but relies purely on statistical heuristics to prioritize and give as immediate feedback as it possibly can, while still guaranteeing you the correct feedback.

Note the highlit words in the previous sentence. Immediate while correct. That is the core philosophy of Continuous Testing for Visual Studio. In the end, correct feedback matters infinitely much more than fast feedback when it comes to testing. Continuous Testing for Visual Studio tries to give you as immediate feedback as it can, while still giving you correct feedback.

It is up to you, dear reader, to try out the tools and find out which works best for you in your real world project. Try Continuous Testing for Visual Studio. While you do that, I’ll continue improving it.

–

¹ We obviously do static analysis to resolve dependencies etc., but not for optimizing away tests.

From now on, Continuous Testing for Visual Studio will be available in two flavors: A full-featured Professional version and a free version staying more or less as it is today.

Continuous Testing 2.0

Buy Professional

Download for VS2010

Download for VS 2008

The new Professional version features a number of improvements over the free version:

• Smart Test Run Prioritization records the outcome of each of your tests, and orders the next test runs to minimize your wait for feedback even further. Smart Test Run Prioritization will run your tests in order of most recently failing and most often failing. This provides a significant speed-up for larger projects.
• Abort on first failing test: You can choose to have Continuous Testing abort as soon as a test fails. This is useful for freeing up resources acquired by the test run as soon as feedback is available. This is another must-have feature in real world software development on large projects.
• Priority support: Send an e-mail and get a response within 24 hours.

The combined features of Continous Testing Professional make for a very powerful and efficient TDD workflow.

Ensuring the last failing test runs first and aborting as soon as a test fails enables you to do as much as possible of what you are supposed to do: Write code.

The free version will continue to stay free with at least the current features. Here are the most notable new features of the free version:

• A new integrated version of the test runners for MSTest and NUnit speeds up test runs. The executable test runners are still available. If you experience problems with running your tests using the integrated runners, try running your tests using the executable test runners instead.
• Continuous Testing can be told to ignore specific projects when scanning for tests. This is useful if you are working on a solution with many test projects, and only want to run some of those projects.
• Continuous Testing now has its own Output Window pane. Watch this pane to see what Continuous Testing is doing.

In addition, many improvements and bug fixes have made it into the release, ensuring a more stable and productive experience than before.

Happy testing and TDD-ing!

JSUT (JavaScript Unit Testing) is an attempt at making such a tool for fun and profit (non-monetary).

JSUT stems from me growing tired of the hurdles of unit testing my JavaScript code. There are tons of alternative unit testing tools and libraries readily available, but my experience was that they all exhibited one or more of the following shortcomings:

• Imposing a “framework” or “philosophy” or “style” on my tests
• Bringing me additional dependencies to worry about
• Working only in the browser or inside Node.js

In addition, I feel that many of the available tools and libraries are either undermaintained or overly featureful, and buggy and/or painful to use as a result of one or both of those. I can’t and won’t claim that this will be different in the case of JSUT, so it’s not really an argument, but more a motivation for me.

Goals

I sat down and wrote a few goals for JSUT:

• Universal, cross-platform
• Minimalistic, simple, non-constraining
• Accessible

I then took to writing code and brushing up my rather rusty shell scripting skills, and a few hours later I wound up with what I present to you now.

JSUT – JavaScript Unit Testing – An introduction

Writing a test in JSUT is about as simple as it can get. You write a function:

function myTest(test) {
  // JSUTs only requirement:
  // Call test.done() when the test is done
  test.done(); 
}

Now, let’s say you save this function to a file called test.js. You can then move to your preferred shell and write the following:

jsut -b chrome test.js

This will run your test in Chrome. To run your test in Node.js, do:

jsut -n test.js

You can combine the -b and -n flags any way you like, of course.

Getting JSUT

Getting JSUT is very simple. Assuming you have npm, just do:

npm install jsut

Which will install jsut locally. If you want a global installation, issue:

npm install jsut -g

Of course, with the goals for JSUT, you can also just download and copy deploy JSUT. Visit http://github.com/havard/jsut for source code and further instructions.

Requirements

As mentioned in the above sample, the only requirement JSUT imposes on you is to call test.done() when your test is done. Obviously, this seems redundant for the simple case of a synchronously executing function, but since most JavaScript functions these days are asynchronous at some level, there has to be a way to tell JSUT that a test is done. I am actively considering easing this requirement for simple cases, but this has not been a priority so far.

For Node.js, you are required to add the functions you want to test to the exports of each test file. Building on the example above, you can maintain cross-platform compatibility by doing the following:

if (typeof(exports) !== 'undefined') {
  exports.myTest = myTest;
}

This will add exports only if the exports variable is defined. Now, if you wanted to run your test in Node.js, you simply do:

jsut -n test.js

This will run your test in Node.js. You are free to combine the -n and -b flags any way you like, so that you can target all required platforms with a single command.

Assertions

JSUT automatically injects a CommonJS compatible assert module in your browser tests, so you can write stuff like assert.ok(true); anywhere in your test.

Planned features

JSUT currently only runs browser tests on OS X. I plan to support Linux and Windows as soon as possible. Follow me and JSUT on GitHub!

Thankfully, Git is highly configurable, and the fix is rather easy:

1. Set i18n.commitencoding to the codepage you’re on in cmd.exe (I’m on windows-1252)
2. Set i18n.logoutputencoding to the same codepage.
3. Set the LESSCHARSET environment variable to a proper name for the code page you’re on (I’m on latin1), either by:
   • Adding a user environment variable in Control Panel > System and Security > System > Advanced System Settings > Advanced > Environment Variables..., or…
   • Setting it your cmd.exe session (e.g. set LESSCHARSET=latin1)

Boilerplate version for your copy-paste convenience (replace encodings as necessary):

git config --global i18n.commitencodig windows-1252
git config --global i18n.logoutputencoding windows-1252
set LESSCHARSET=latin1

The first setting tells Git how your commit messages, including your author information, are encoded. The second tells Git what encoding it should use when writing output from a command like git log. The third and final setting tells less, the pager that Git runs git log output through, what encoding to use.

API changes

The API of the entire thing has changed. All callbacks exposed and used by the library are now on the form callback(error, args). This convention is familiar to Node.js developers, and gives us the advantage of simpler integration with other libraries, as well as a slight increase in the fidelity of error messages.

What has changed?

• authenticate now expects a callback which will be called with (error, authUrl). Existing code which expects (authUrl) will not get an authUrl (but possibly an error instead), and so authentication won’t work after upgrade until you change your code.
• verifyAssertion also expects a callback of the same form, which will be called with (error, result). Again, existing code depends on receiving a (result) call, and will break.
• loadAssociation and saveAssociation must now accept a callback on the form (error, result) as an additional parameter. Previously, these functions were synchronous, so existing implementations will have to adapt so they call the callback rather than return.

What is new?

As usual, we have fixed several bugs. The library is gaining a community, and there have been several contributions along the 0.1 release path leading up to 0.2.0. Thank you all for your participation!

Apart from the changes above, 0.2.0 also introduces a discovery cache for caching discovered information. This cache is used to avoid additional HTTP requests when verifying assertions from the OpenID providers. The default cache is an in-memory cache, but you can implement your own by overloading two functions:

• loadDiscoveredInformation(claimedIdentifier, callback) is expected to look for and load a cached provider for the given claimedIdentifier. It is expected to call callback(error, provider) when finished, with either an error or a provider (duh).
• saveDiscoveredInformation(provider, callback) is expected to cache the given provider. The key for this object is provider.claimedIdentifier, which loadDiscoveredInformation uses for lookup. After saving, the function is expected to call callback(error) with an error if something failed, or nothing if all went well.

I have been very reluctant to make these significant API changes, but the recent development, reported issues, and feature requests have convinced me that a unified API, and a more familiar API for Node.js developers, is the right way. Also, adapting to the new API is a pretty easy process. I hope you agree with me that the introduction of these changes is best in the long run.

A brief API overview:

• crypto.createDiffieHellman(prime_length)
  • Creates a Diffie-Hellman key exchange object and generates a prime of the given bit length. The generator used is 2.
• crypto.createDiffieHellman(prime, encoding='binary')
  • Creates a Diffie-Hellman key exchange object using the supplied prime. The generator used is 2. Encoding can be 'binary', 'hex', or 'base64'.
• diffieHellman.generateKeys(encoding='binary')
  • Generates private and public Diffie-Hellman key values, and returns the public key in the specified encoding. This key should be transferred to the other party. Encoding can be 'binary', 'hex', or 'base64'.
• diffieHellman.computeSecret(other_public_key, input_encoding='binary', output_encoding=input_encoding)
  • Computes the shared secret using other_public_key as the other party’s public key and returns the computed shared secret. Supplied key is interpreted using specified input_encoding, and secret is encoded using specified output_encoding. Encodings can be 'binary', 'hex', or 'base64'. If no output encoding is given, the input encoding is used as output encoding.
• diffieHellman.getPrime(encoding='binary')
  • Returns the Diffie-Hellman prime in the specified encoding, which can be 'binary', 'hex', or 'base64'.
• diffieHellman.getGenerator(encoding='binary')
  • Returns the Diffie-Hellman prime in the specified encoding, which can be 'binary', 'hex', or 'base64'.
• diffieHellman.getPublicKey(encoding='binary')
  • Returns the Diffie-Hellman public key in the specified encoding, which can be 'binary', 'hex', or 'base64'.
• diffieHellman.getPrivateKey(encoding='binary')
  • Returns the Diffie-Hellman private key in the specified encoding, which can be 'binary', 'hex', or 'base64'.
• diffieHellman.setPublicKey(public_key, encoding='binary')
  • Sets the Diffie-Hellman public key. Key encoding can be 'binary', 'hex', or 'base64'.
• diffieHellman.setPrivateKey(public_key, encoding='binary')
  • Sets the Diffie-Hellman private key. Key encoding can be 'binary', 'hex', or 'base64'.

NOTE: The API is still subject to change.

I would appreciate getting a note if you actually do something useful with it. Play around with it and let me know what you think!

Installation

Installing is very simple using npm:

npm install openid 

If you don’t use npm, you can of course just download and require. Remember dependencies from the lib folder, and remember adding paths to require.paths if necessary.

Usage

One of the main design goals for the library has been simplicity. Using OpenID for node.js is pretty simple, here’s a minimal sample server:

var openid = require('openid');
var url = require('url');
var server = require('http').createServer(
    function(req, res)
    {
        var parsedUrl = url.parse(req.url, true);
        if(parsedUrl.pathname == '/verify')
        {
            // Verify identity assertion
            var result = openid.verifyAssertion(req); // or req.url
            res.writeHead(200);
            res.end(result.authenticated ? 'Success  ' : 'Failure  ');
        }
        else if(parsedUrl.pathname == '/authenticate')
        {
            // Resolve identifier, associate, build authentication URL
            openid.authenticate(
                parsedUrl.query.openid_identifier, // user supplied identifier
                'http://example.com/verify', // our callback URL
                null, // realm (optional)
                false, // attempt immediate authentication first?
                function(authUrl)
                {
                    res.writeHead(302, { Location: authUrl });
                    res.end();
                });
        }
        else
        {
            // Deliver an OpenID form on all other URLs
            res.writeHead(200);
            res.end('<!DOCTYPE html><html><body>'
                + '<form method="get" action="/authenticate">'
                + '<p>Login using OpenID</p>'
                + '<input name="openid_identifier" />'
                + '<input type="submit" value="Login" />'
                + '</form></body></html>');
        }
    });
server.listen(80);

Source

I use GitHub for source control, so you can follow me and the node-openid repository there.

Licensing

OpenID for node.js is licensed under the MIT license. Details can be found in the LICENSE file on GitHub. The library includes third-party code released under the MIT and BSD licenses, see README for details.

Wishes for node.js

I’ve come across a couple of missing features which I’d love to see in node.js in the near future:

• The crypto module should support Diffie-Hellman key exchange (OpenSSL supports it, so please provide bindings)
• A big integer library should be available alongside the crypto module, and preferably seamlessly integrated with the crypto module – perhaps bindings to the GMP library could suffice?
• More seamless unit testing libraries would be good

In addition, I would love to see a tailored IDE for node.js applications.