How to Build a Real-Time Chat Service with Socket.IO, Express, and the Azure SDK–Part 2: Setting Up Express and Session-Handling

So if you read part 1 of this series, then you’ve had a chance to grok the requirements for our little chat service and see all of the NPM packages and front-end tools we’re going to use for building it. In this portion I’m going to explain how to set up Express and all of the session-handling requirements we have.

If you recall from the previous post, we need to ensure that all users participating in the chat room are signed in with a registered chat handle before they can participate. We’re going to accomplish that using the Express web framework and its rich user-session support.

Step 1: Install Express and its dependencies

The first thing we need to do is install Express itself, which is pretty straightforward – do the following:

   1: $ npm install -g express 
   2: $ express nodebootcamp-chat
   3: $ cd nodebootcamp-chat
   4: $ npm install


Notice that I use the npm install –g command – that installs Express globally and makes it accessible to 100% of Node projects on my local system; this is convenient because it allows you to use Express’ scaffolding for creating new websites without having to install Express first each and every time.

Step 2: Rename app.js to server.js

Windows Azure’s Node runtime looks for an entry point to your application with the filename server.js in the root directory; Express’ default entrypoint file



Step 3: Set up cookie-sessions to be the Express session provider

We’re going to use cookie-sessions as our cookie mechanism for our chat application because it doesn’t require us to set up a Redis / MongoDB session store.

So I added cookie-sessions to my package.json file and modified the top of server.js accordingly:

   1: var express = require('express')
   2:   , routes = require('./routes')
   3:   , http = require('http')
   4:   , sessions = require('cookie-sessions');
   6: var app = express();
   8: app.configure(function(){
   9:   app.set('views', __dirname + '/views');
  10:   app.set('view engine', 'jade');
  11:   app.use(express.favicon());
  12:   app.use(express.logger('dev'));
  13:   app.use(express.static(__dirname + '/public'));
  14:   app.use(express.bodyParser());
  15:   app.use(sessions({secret: 'A UNIQUE SESSION KEY'}));
  16:   app.use(express.methodOverride());
  17:   app.use(app.router);
  18: });

This code imports the cookie-sessions module (line 4) so we can use it anywhere inside of server.js, and then sets it as the official session provider throughout all requests handled by the Express server (line 15).

In order to leverage the session provider you have to call app.use(sessions({….})) before the app.use(app.router) is called – any Express configuration that isn’t set before the call app.router to effectively gets ignored since app.router intercepts all requests and does the actual handling from that point onward, and all of these configuration options are loaded in sequential order.

Session Secrets

One small thing to point out:

  15:   app.use(sessions({secret: 'A UNIQUE SESSION KEY'}));

The session key string that we’re using is used to create a secure two-way hash so the cookies can only be decrypted by your application. You can set this secret string to be anything – I typically use a uuid.

Bear in mind that if you change this session key after your application has been deployed that you’ll no longer be able to decrypt any previously-assigned cookies, so all of your users will have to log out and log back in again.

Step 4: Create route helpers to enforce authentication rules and activate session cookies

Now that we have session support via cookie-sessions, we have to do two things to leverage it in our project:

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..