The JavaScript blog.


iojs node security

Security Updates: Node 0.12 and io.js

Posted on .

Today security updates for Node 0.12, io.js 2.3 and io.js 1.8 were released due to a UTF-8 decoding bug in V8:

Here's the technical overview from the io.js Medium post:

Kris Reeves and Trevor Norris pinpointed a bug in V8 in the way it decodes UTF strings. This impacts Node at the Buffer to UTF8 String conversion and can cause a process to crash. The security concern comes from the fact that a lot of data from outside of an application is delivered to Node via this mechanism which means that users can potentially deliver specially crafted input data that can cause an application to crash when it goes through this path. We know that most networking and filesystem operations are impacted as would be many user-land uses of Buffer to UTF8 String conversion. We know that HTTP(S) header parsing is not vulnerable because Node does not convert this data as UTF8. This is a small consolation because it restricts the way HTTP(S) can be exploited but there is more to HTTP(S) than header parsing obviously. We also have no information yet on how the various TLS terminators and forward-proxies in use may potentially mitigate against the form of data required for this exploit.

Node 0.10 is not affected. Thanks to Rod Vagg for letting me know about this!


node iojs

Node: Long-Term Support Working Group

Posted on .

On Monday the Node Long-term Support Working Group met to discuss plans for Node's future release schedule. The plan is described as a strawman LTS plan, meaning it's preliminary and hasn't yet been approved. There's a discussion on GitHub about it that I found through this Tweet (retweeted by @rvagg which is seemingly how I learn everything about io.js/Node):

The plans are based on several assumptions -- again, nothing is official yet. One assumption is that the next major and officially supported Node release will be from the merged io.js/Node project, and will follow io.js's versioning. Subsequent major releases will be yearly, and will transition into maintenance after 18 months. There's a handy visualisation of the release schedule:

Node strawman LTS

The author (James M Snell) just posted that 0.12 might see a slightly shorter 0.12 LTS release, so if you're (hypothetically) planning maintenance work based on these plans then you might want to take that into account. I very much hope this comes together, because a major Node release that includes io.js would be pretty exciting for server-side JavaScript programmers.


modules events conferences iojs libraries node npm

Node Roundup: 0.12.5, 0.10.39, io.js 2.3.1, NodeDay, Apey Eye

Posted on .

Node 0.12.5, 0.10.39, io.js 2.3.1

Two new releases of Node just came out. Both releases fix OpenSSL security issues, but 0.12.5 also includes updates for uv and npm.

io.js 2.3.1 was also released this week. One of the big changes in this release is performance improvements for require:

module: The number of syscalls made during a require() have been significantly reduced again (see #1801 from v2.2.0 for previous work), which should lead to a performance improvement (Pierre Inglebert) #1920.

This sounds very nice for large projects.



NodeDay is a conference being held in London on 26th June (this Friday), for free! Speakers include Lin Clark, who writes npm's excellent blog posts, and programmers from the BBC, Red Hat, and other companies that are using Node for interesting things.

nodeday is a Node.js conference by the enterprise, for the enterprise. Now in its second year, this one-day industry conference brings together people from companies that have adopted or are planning to adopt Node.js, and focuses on the issues that these companies face. It gives participants a forum to discuss and share their experiences with Node.js, share advice, tips and tricks, and drive forward both the technology and the community.

I apologise for not writing about this sooner, but I only just found out about it! If you have conferences you want me to cover on DailyJS, you can use the contact forms or message me on Twitter (@alex_young).

I really wanted to go to NodeDay but I can't make it this time.

Apey Eye

Filipe Sousa sent in Apey Eye (GitHub: https://github.com/glazedSolutions/apey-eye, License: MIT, npm: apey-eye):

Apey Eye is an Object-Resource Mapping Node.js API framework that uses next-generation JavaScript features that can be used today, like Classes, Decorators and async/await for maximum expressiveness.

This is a framework for building data layers that map directly to REST APIs. It's a bit like ORM for HTTP. It comes with base classes for routing, REST resources, models, and validation, and the models can serialise data to RethinkDB. To talk to other databases a new base model class would have to be written.

Thanks to ES6, the model syntax is very clean:

let Model = ApeyEye.Model;

class MyModel extends Model {  
    constructor() {
        super(async function() { (...) });

    static async fetch() { (...) }
    static async fetchOne() { (...) }
    async put() { (...) }
    async patch() { (...) }
    async delete() { (...) }

To me this looks like C# without the extra syntax for strong typing. The validation API looks similar to what you might have seen before with modules like Mongoose.

I like the idea of object-resource mapping at the HTTP level. In Node web apps we seem to spend a lot of time thinking about HTTP servers and APIs, so this feels like it could reduce the amount of boilerplate required to interface from that step to the database layer.


node iojs

Node.js Foundation: New Members, Technical Governance

Posted on .

After io.js joined the Node Foundation, there's now the news that the industry backers and developer communities behind the Node.js Foundation are working together to ratify the "open governance structure":

The open, technical governance model that will guide the project was determined with input from the public, including contributors from both the Node.js and io.js communities. The model includes a Technical Steering Committee that will direct technical decisions, oversee working group projects and manage contributions to the node code base, and a Board of Directors to guide business decisions.

Joyent's CEO, Scott Hammond, wrote a blog post that ties in with the announcement:

There's a lot of work ahead to secure a successful future for Node.js. While crucial, an open governance model by itself does not guarantee long-term success. We'll need to balance the needs of the strong developer community with those of the users and encourage a vibrant ecosystem of technology and service providers to ensure the bright future we all envision. And the best way to strike this balance is through a community-driven, neutral foundation.

The PR behind all of this has been much more professional than what I've previously seen from Node, so I'm still cautiously optimistic about the development of the Foundation and its implications for us, as JavaScript programmers. The industrial backing is impressive:

Founding and new members include Platinum members Famous, IBM, Intel, Joyent, Microsoft and PayPal. Gold members include GoDaddy, NodeSource and Progress Software, and Silver members include Codefresh, DigitalOcean, Fidelity, Groupon, nearForm, npm, Sauce Labs, SAP, StrongLoop and YLD!.

But what about The Great Merge of 2015? The press release does say that the "Node.js and io.js developer communities today are announcing a collaboration to merge their respective code bases" – but I'm still not clear about when and how this is happening.

Meanwhile, io.js 2.3.0 is out, and Node is still at 0.12.4 (stable). If you're invested in Node my advice is to keep following io.js releases closely. I still see a lot of apps running 0.10.x in production. If you're at the latest security patched version then I wouldn't worry too much about switching over to io.js just yet. However, there's no harm in having a branch in your project that runs unit tests against io.js.


database ORM iojs frameworks ES6 node express

Node Roundup: io.js 2.2.1, firenze.js, Express Happiness

Posted on .

io.js 2.2.1

io.js 2.2.1 has been released. The notable change in this release is the switch back to this.client in the IncomingMessage constructor in the http core module. The original change broke compatibility with request, which is used by npm. The io.js contributors found out about it by running make test-npm. There's an interesting discussion about it in the io.js pull requests.


Fahad Ibnay Heylaal sent in firenze.js (GitHub: fahad19/firenze, License: MIT, npm: firenze), an ORM for SQL written in ES6. It's built with Babel so it should work with Node 0.10.x and 0.12.x.

The API is promise based:

var posts = new Posts();  
posts.find('first', {  
  conditions: { id: 1 }
}).then(function(post) {
  var title = post.get('title');
  var postObject = post.toObject();
  var title = postObject.title;

To define a schema, you first describe a collection (table) and then a model:

var Posts = db.createCollectionClass({  
  table: 'posts',
  modelClass: function () {
    return Post;

var Post = db.createModelClass({ // or db.Model()  
  alias: 'Post',
  collectionClass: Posts,
  schema: {
    id: { type: 'integer' },
    title: { type: 'string' },
    body: { type: 'text' }

But you can also use cool ES6 syntax like this:

class Post extends f.Model {  
  constructor(attributes = {}, extend = {}) {
    super(attributes, extend);

The project has a lot more methods for querying and saving data -- take a look at the project's homepage to see the full documentation.

Express Happiness

Express Happiness (GitHub: andreas-trad/express-happiness, License: WTFPL, npm: express-happiness) by Andreas Trantidis is a framework built on Express that offers the following features:

  • A JSON route tree
  • Strictly defined, centralised error handling
  • Route permissions
  • Parameter validation
  • Automatic REST API documentation generation
  • Data mocking

Validation is automatic, which means each parameter a route receives is defined in terms of the type. The route tree looks like what you might expect: a list of paths with HTTP verbs that map to RESTful methods. Routes can also be dynamic so you can include parameters.

Because the error handling is all in one place it's a lot easier to manage than a basic Express application. You can easily define error handlers for 404, 500, and any other error codes, and the framework will send the right thing back to the client.

The validation performed by Express Happiness is done through validator, which is a popular and well-maintained validation module.