Prevent Redis client from crashing your Node.js app

Posted on 1 Comment
Credit: http://crash.rocks/
Credit: http://crash.rocks/

Redis is a high-performance in-memory database that is often used for data caching on server-side. The redis npm package makes is nice & easy to use Redis to cache data in a Node app. If you are new to Redis, you will find this tutorial on Coligo helpful in implementing data caching in your own application. It often results in 10x or more performance increase. Don’t take my work, check it out yourself!

An annoying issue with the redis package is that, if Redis server is not running, doing this emits an uncaught exception, crashing the whole app:

redisClient = redis.createClient();

As this operation, like most operations in Node, is asynchronous, using try-catch simply doesn’t work.

My solution is to create a singleton Redis client instance that handles the Redis-server-not-running case through its retry_strategy option. When Redis server is not running, my singleton returns a fake Redis client that has same function names as the real Redis client. This gives me the benefit of using redis package’s code the way it’s advertised on its documentation without any additional error handling code and without worrying about whether Redis server is running.

I hope my code helps you too. Just create a file redisClient.js somewhere in your Node app and require it when you need to use it.

var redisClient = require('common/redisClient');
 
...
 
var redis = redisClient.getClient();
redis.setex(unique_key_name, 60, data_to_be_cached);

 

/////////////////////////////////////////////////
// Singleton for Redis cache database client.
//
// @file: redisClient.js
// @author: Anurag Bhandari
/////////////////////////////////////////////////
 
var redis = require('redis');
 
var redisClient = (function () {
 
    // Start with a fake client so that we have a client that works
    // even when Redis server is down
    var client = {
        get: function (key, cb) {
            cb(null, null);
        },
        setex: function (key, time, value) {
            // Do nothing in particular
        }
    };
 
    // Attempt to create a new instance of an actual redis client
    var connectionString = process.env.REDIS_URL || 'redis://localhost:6379';
    var c = redis.createClient(connectionString, {
        retry_strategy: function (options) {
            if (options.error.code === 'ECONNREFUSED') {
                // This will suppress the ECONNREFUSED unhandled exception
                // that results in app crash
                return;
            }
        }
    });
 
    // Set the "client" variable to the actual redis client instance
    // once a connection is established with the Redis server
    c.on('ready', function () {
        client = c;
    });
 
    /**
     * Get a redis client
     * @return {Object} client - eventually a proper redis client object (if redis is up) or a fake client object (if redis is down)
     */
    var getClient = function () {
        return client;
    };
 
    return {
        getClient: getClient
    }
 
})();
 
module.exports = redisClient;

Authentication for your Node/Express based APIs

Posted on Leave a comment

This post is not a tutorial, just some thoughts on the topic. There are plenty of tutorials out there that talk about protecting your RESTful Node/Express based APIs using some form of token-based authentication. Some of them are pretty straightforward to follow, some not. But most of them have one thing in common — delegating the authentication part to Passport.js. While that’s not a bad idea, using Passport.js for anything other than basic HTTP authentication can be bewildering, especially when you want to implement a more secure auth such as OAuth or HTTP Bearer.

HTTP Basic Authentication is a big NO-NO

Never, ever think of doing this just for the sake of making it easy to call your APIs from client-side code. Basic authentication is insecure. Period. It’s way too easy to crack.

Start with a simple JWT-based Token Authentication

Credit: https://jwt.io/introduction/
Credit: https://jwt.io/introduction/

JWT has pretty much become the standard auth token format. It’s used by small to large enterprises alike. Before actually taking the dive, it will immensely help to understand the anatomy of JWT. Once you’ve done that, give this tutorial a read. It’s one of the best and easy to follow tutorials I’ve come across on this topic.

TL;DR — JWT is a self-contained piece of information. It makes session-based auth a thing of the past. No more creating database tables to store user sessions and no more writing server-side logic to handle them. jsonwebtoken npm package makes it easy to integrate a JWT-based auth flow in a Node/Express based application. Most of the magic happens in your API router’s middleware, which acts as the single place to authenticate ALL your APIs.

Use bcrypt for storing hashed passwords

Credit: http://stackoverflow.com/questions/27592732/what-should-be-stored-in-table-while-using-bcrypt
Credit: http://stackoverflow.com/questions/27592732/what-should-be-stored-in-table-while-using-bcrypt

If you’ve gotten this far in this post, I’m sure you know to NEVER STORE PASSWORDS IN PLAIN TEXT. People have amazing theories. Some n00bs make the mistake of storing plain text passwords, thinking that modern database systems are themselves secure enough and unhackable. They are totally wrong. Yes, database vendors like Oracle and Microsoft do their best to make their systems highly secure and robust but what good is that security when the app itself is stupidly vulnerable?

Developers who realize this bit actually store passwords as irreversible hashes, sometimes relying on good ol’ MD5 or SHA-1 algorithms. But even these aren’t secure enough. There are better and more secure hashing algorithms, such as bcrypt. I’ve found the bcrypt-nodejs npm package to be pretty straightforward.