The full app is available on GitHub the article will go through only important parts.

I don't want to get into details for each method, we will discuss them at in the appropriate article. I would like to focus on the e-mail and password authentication. This is the most simple, yet in many cases wrongly implemented. Don't get me wrong probably this implementation will become obsolete someday, due to frequent changes and loop holes in security.

Many people don't take security seriously enough when building their application from scratch. Many companies have invested millions in proper security systems for their platforms. So this should raise an alarm when we talk about the security of our application.

Short list of best practices

This is my list of best practices when dealing with e-mail and password authentication (suggestions are much appreciated):

• Do not store passwords in plain text in DB.
• Generate password hash using a key stretching/derivation function.
• Generate a random salt for each user.
• Do not return password and salt in results from DB query.
• Return password and salt only if explicitly requested.
• Do not persist user sensitive data in sessions, like password and salt.
• Try to be "slow" when computing hashes.
• Throttle multiple requests for login request.
• Throttle bad login attempts.
• Consider using something like helmet.

About the authentication strategy

Probably you all have seen a simple login form with e-mail and password fields. Almost every website or application has a similar login mechanism. The magic behind this is very simple, a user inserts the e-mail and password used on registration, which is matched against the persisted values in the database.

Obviously the implementation is a bit more complex. First, we don't store the user's password in the database, instead we store a one way derived key (or hash) of the password in a stretched form. One way means that we cannot revert the process and get the initial password from the hash. Stretched means, that regardless of the user's password length we are always going to have a string of, let's say 40 characters.

Secondly, we want to have something unique for each user, to combine it with the user's password, so that we don't obtain the same hash for the same password for two users, we will call this the salt. Like we and salt and pepper in food, to get different flavors.

Application structure

    app
    -- controllers
    ---- authenticaiton.js
    ---- account.js
    -- models
    ---- user.js
    -- helpers
    ---- password.js
    -- middlewares
    ---- authentication.js
    -- routes
    ---- authentication.js
    ---- account.js
    ---- main.js
    -- views
    ---- home.html
    ---- signin.html
    ---- signup.html
    ---- account.html
    config
    -- environments
    -- strategies
    ---- local.js
    -- index.js
    -- express.js
    -- passport.js
    -- mongoose.js
    -- routes.js
    -- models.js
    public
    tests
    -- unit
    -- integration
    package.json
    server.js

This is a conceptual application structure, I've used my express starter app. We'll only focus on some parts of the application and the rest of the application will be available on GitHub.

Hashing the password

We discussed that we cannot store the user's password in plain text in the database, because of security reasons. Beside that, we have to combine the password with a salt.

In order to hash the password we can use Node's built in crypto module. An alternative would be to use bcrypt for node.js, but I will let you figure out what suits your needs.

Generally people think that password hashing should be fast. But, its the other way around, when hashing password, I want it to be slow as possible, not slow as a lazy cat, but slow enough to be expensive to compute.

Why expensive to compute? Well because MD5 is super fast, too fast, you can generate all the possible passwords of 6 characters long in tens of seconds. You could use MD5 like this, M5(password + salt), but will not help you. With the proper hardware you could crack and try as many possibilities as you want.

Solution?

Password stretching, and password stretching. Let's say that to generate our hash, it takes 200ms. To generate 10 passwords using the same algorithm would take 2000ms, which is 2 seconds, obviously we can use parallel computing to reduce the time needed, but this is not the case. Hence the computing necessity increases, and becomes time consuming.

Be advised that this can be a double edged blade, which means it can have side effects, if it takes too long to generate the hash. Try what best suits your needs, there is no one solution for all.

Implementing the password helper

We are going to use crypto.pbkdf2() method, which is a key derivation function. It uses an HMAC digest function, like SHA1, to create a derived key from the password using a salt in a number of iterations.

One important part is the number of iterations. The method uses iterations to create the derived key, which will make it expensive as computing time. If in time the hardware to compute hashes improves we can increase the number of iterations to generate the hash.

We are going to create a file called app/helpers/password.js and add the following content:

'use strict';

var LEN = 256;  
var SALT_LEN = 64;  
var ITERATIONS = 10000;  
var DIGEST = 'sha256';

var crypto = require('crypto');

module.exports.hash = hashPassword;

function hashPassword(password, salt, callback) {  
  var len = LEN / 2;

  if (3 === arguments.length) {
    crypto.pbkdf2(password, salt, ITERATIONS, len, DIGEST, function(err, derivedKey) {
      if (err) {
        return callback(err);
      }

      return callback(null, derivedKey.toString('hex'));
    });
  } else {
    callback = salt;
    crypto.randomBytes(SALT_LEN / 2, function(err, salt) {
      if (err) {
        return callback(err);
      }

      salt = salt.toString('hex');
      crypto.pbkdf2(password, salt, ITERATIONS, len, DIGEST, function(err, derivedKey) {
        if (err) {
          return callback(err);
        }

        callback(null, derivedKey.toString('hex'), salt);
      });
    });
  }
}

The hashPassword() function takes three argmunts: a password, an optional salt and a node.js style callback function. The salt is optional, because we can use this function in two scenarios.

First scenario is, when we want to hash the user's password for the first time, the salt does not exists in this case, and we will generate a random salt using crypto.randomBytes() method to generate a cryptographically strong, pseudo-random string.

The second scenarios will occur, when we already have a user in the database, and a salt exists for that user. In this scenario we are going to use the same salt to generate a hash for the input, to get the same hash as output.

Passport local authentication strategy

We are going to use Passport.js to authenticate users. Passport has many strategies already implemented. First we are going to configure passport for our needs, create a file called config/passport.js, and add the following content:

'use strict';

var passport = require('passport');  
var mongoose = require('mongoose');  
var User = mongoose.model('User');

module.exports.init = function(app) {  
  passport.serializeUser(function(user, done) {
    done(null, user.id);
  });

  passport.deserializeUser(function(id, done) {
    User.findById(id, done);
  });

  // load strategies
  require('./strategies/local')();
};

Secondly, we are going to implement the local strategy, by creating the following file, config/strategies/local.js:

'use strict';

var passport = require('passport');  
var LocalStrategy = require('passport-local').Strategy;  
var mongoose = require('mongoose');  
var User = mongoose.model('User');

module.exports = function() {  
  passport.use('local', new LocalStrategy({
      usernameField: 'email',
      passwordField: 'password'
    },
    function(email, password, done) {
      User.authenticate(email, password, function(err, user) {
        if (err) {
          return done(err);
        }

        if (!user) {
          return done(null, false, { message: 'Invalid email or password.' });
        }

        return done(null, user);
      });
    }
  ));
};

As you can see we are using a custom .authenticate() method from our mongoose User model. Do not worry, we will implement this method shortly. Passport let's us define a middleware to mount a strategy, we are going to call it 'local'. We created a new instance of Passport's local strategy and added our own callback when the strategy is called.

Mongoose User model

We are using MongoDB to persist data, to ease things we are going to use mongoose to define collections and communicate with Mongo. Create a file called app/models/user.js, and add the following lines of code:

'use strict';

var mongoose = require('mongoose');  
var passwordHelper = require('../helpers/password');  
var Schema = mongoose.Schema;  
var _ = require('lodash');

var UserSchema = new Schema({  
  email:  {
    type: String,
    required: true,
    unique: true
  },
  name: {
    type: String
  },
  password: {
    type: String,
    required: true,
    select: false
  },
  passwordSalt: {
    type: String,
    required: true,
    select: false
  },
  createdAt: {
    type: Date,
    default: Date.now
  }
});

// compile User model
module.exports = mongoose.model('User', UserSchema);

The schema is fairly simple, so no explanation is required. One thing to note is that we added { select: false } property to the password and passwordSalt fields. This will prevent them from showing in query results.

Next we are going to add the authentication method, by appending it to the model file after the UserSchema:

UserSchema.statics.authenticate = function(email, password, callback) {  
  this.findOne({ email: email }).select('+password +passwordSalt').exec(function(err, user) {
    if (err) {
      return callback(err, null);
    }

    // no user found just return the empty user
    if (!user) {
      return callback(err, user);
    }

    // verify the password with the existing hash from the user
    passwordHelper.verify(password, user.password, user.passwordSalt, function(err, result) {
      if (err) {
        return callback(err, null);
      }

      // if password does not match don't return user
      if (result === false) {
        return callback(err, null);
      }

      // remove password and salt from the result
      user.password = undefined;
      user.passwordSalt = undefined;
      // return user if everything is ok
      callback(err, user);
    });
  });
};

Before in the user schema we set the password and passwordSalt field to be hidden from the query output. But this time we explicitly request them, so that we can construct the hash using the persisted salt. Afterwards we check if the persisted password hash matched the one generated on the fly.

Authentication controller

We are going to create a controller file called, app/controllers/authentication.js, which is going to consume the local strategy from passport. Add the following lines of code:

'use strict';

var passport = require('passport');

module.exports.signin = signinUser;

function signinUser(req, res, next) {  
  // add validation before calling the authenicate() method

  passport.authenticate('local', function(err, user, info) {
    if (err || !user) {
      return res.status(400).send(info);
    }

    req.logIn(user, function(err) {
      if (err) {
        return next(err);
      }

      // you can send a json response instead of redirecting the user
      //res.status(200).json(user);

      res.redirect('/');
    });
  })(req, res, next);
};

The controller exports a .signin() method that calls the local strategy, and redirects the user to the root path of the application, in case of a successful sign in. We could add validation before executing the local strategy, but we are going to keep it simple as possible for now.

Defining the authentication route

In order for everything to work we need to expose an endpoint, create a file called app/routes/authentication.js:

'use strict';

var express = require('express');  
var router = express.Router();  
var authCtrl = require('../controllers/authentication');

router.post('/signin', authCtrl.signin);

module.exports = router;

I'm using the Router class from Express to create a new route instance and later on mount it to the main express application. This way you can easily reuse defined routes and add prefixes as desired.

A simple way to mount the preceding route in your Express app, is with the following code:

app.use('/', require('./app/routes/authentication'));

Considerations for session storage

Passport requires to be initialized and also call the passport.session() method to persist sessions. This method requires the express session to be present. For the express session I use mainly two configurations, one for development and one for production.

The reason why I use two is because by default session information is stored in memory, you don't want this for a production environment, because of memory leaks. Another reason for this could be shared sessions states, when you run your node application in cluster mode.

A simple solution would be to use a persistent storage, because we already use MongoDB, we could simply use it for our session store. There is a very nice implementation called connect-mongo. An alternative solution would be to use connect-redis to store sessions in Redis.

Sample of implementaion found in config/express.js:

  var sessionOpts = {
    secret: config.session.secret,
    key: 'skey.sid',
    resave: false,
    saveUninitialized: false
  };

  switch(env) {
    case 'production':
      sessionOpts.store = new MongoStore({
        url: config.mongodb.uri
      });
    case 'staging':
    case 'test':
    case 'development':
    default:
      app.use(session(sessionOpts));
  }

  /**
   * Use passport session
   */
  app.use(passport.initialize());
  app.use(passport.session());

The full source code can be found on here.

Thanks for reading.

The technology stack was pretty simple, Nginx serving us on the front of the battle field and passing some of the requests to the node.js web server. For data storage we went with MongoDB, we hopped on the NoSQL wagon and just rolled with it. And as in many other projects we needed some sort of file management. Did some research and had to give a try to gridfs. So we used gridfs to manage and serve images (and in the future also other files too).

What’s this GridFS

To be short MongoDB can be used as a file system.

From the manual:

GridFS is a specification for storing and retrieving files that exceed the BSON-document size limit of 16MB. Instead of storing a file in a single document, GridFS divides a file into parts, or chunks, and stores each of those chunks as a separate document.

Probably now you ask yourself, can I store files smaller than 16MB? the answer is YES. You can store any size of files, all the files are going to be chopped up in chunks. Should I use gridfs if my files are under 16MB? It depends on your use case, I would suggest you do to some tests and research before using it, maybe it's enough to use the simple BSON model.

So for using gridfs the advantages are numerous, for example you can take advantage of load balancing and data replication features over multiple machines for storing files. Also your files are splitted in small chunks. So for example getting a portion of your video file should be fairly easy to do.

GridFS by default uses two collections: fs.files and fs.chunks to store the file's metadata and the chunks. Each entry in the chunks collection represents a small piece from a file. A document from the chunks collection contains the following fields:

{
  "_id" : <ObjectId>,
  "files_id" : <ObjectId>,
  "n" : <num>,
  "data" : <binary>
}

The files collection holds the parent file for the chunks. Applications may add additional fields to the document. An example document from the files collection could look like this:

{
  "_id" : <ObjectId>,
  "length" : <num>,
  "chunkSize" : <num>,
  "uploadDate" : <timestamp>,
  "md5" : <hash>,

  "filename" : <string>,
  "contentType" : <string>,
  "aliases" : <string array>,
  "metadata" : <dataObject>,
}

Node.js integration

As express.js is so popular I’m going to jump right ahead and show you a simple integration. I’m going to use some existing code from one of my previous posts about file upload

I’m going to use mongoose as it’s a fairly familiar module for mongodb. Create a separate file mongoose.js for your mongoose configuration and DB connection. Also I’m going to use gridfs-stream to stream files to and from mongo.

var mongoose = require('mongoose');  
var Grid = require('gridfs-stream');

// @param {Object} app - express app instance
module.exports.init = function(app) {  
  var Schema;
  var conn;

  Grid.mongo = mongoose.mongo;
  conn = mongoose.createConnection(‘mongodb://localhost/aswome_db’);
  conn.once('open', function () {
    var gfs = Grid(conn.db);
    app.set('gridfs', gfs);
    // all set!
  });

  app.set('mongoose', mongoose);
  Schema = mongoose.Schema;
  // setup the schema for DB
  require('../db/schema')(Schema, app);
};

Now you can use it in a controller of your choice. Let’s create a file file_controller.js this will upload a file to the server write it into the database and delete the temporary file from the disk. The best part is that you can use streams to write into the database.

var shortId = require('shortid');

// @param {Object} app - express app instance
module.exports = function(app) {  
  // get the gridfs instance
  var gridfs = app.get('gridfs');

  return {
    upload: function(req, res, next) {
      var is;
      var os;
      //get the extenstion of the file
      var extension = req.files.file.path.split(/[. ]+/).pop();
      is = fs.createReadStream(req.files.file.path);
      os = gridfs.createWriteStream({ filename: shortId.generate()+'.'+extension });
      is.pipe(os);

      os.on('close', function (file) {
        //delete file from temp folder
        fs.unlink(req.files.file.path, function() {
          res.json(200, file);
        });
      });
    } 
  };
};

Reading a file from gridfs should be fairly easy. Just add a new method to your controller.

getFileById: function(req, res, next) {  
      var readstream = gridfs.createReadStream({
        _id: req.params.fileId
      });
      req.on('error', function(err) {
        res.send(500, err);
      });
      readstream.on('error', function (err) {
        res.send(500, err);
      });
      readstream.pipe(res);
}

The best thing is that you can store additional information with the files. So for example file access policies should be straightforward to implement, and could be stored with your files inside the files collection.

Is GridFS fast and reliable enough for production?

I came across this stackoverflow question, you also may find it usefull. From my perspective it’s a simpler way to implement file management systems as it’s straightforward gives you a lot of flexibility and out of the box features. And for some reasons I can live with the slowness it adds.

There is also a nice article about the performance of GridFS.

What can be improved?

If you are using nginx to serve static files then it could be nice to integrate it directly with gridfs to server the images and add caching to them. And as my earlier research showed me this can be done pretty fast and simple, but this could be a topic of another post.

Thanks for reading.

Authentication

Authentication verifies who you are. For example, in reality, if you buy a ticket to a concert and present it at the entrace you are authenticaticating that you are the person who bought that ticket. In computer science you can authenticate to a unix server using ssh.

Authorization

Authorization verifies what you can do. Let's say you are stopped by a police car when driving home from work. He will eventually ask for your drivers licence, this will permit him to check if you are authorized to drive that car. Getting back to our unix server example, you are allowed to login to your system via ssh client, but you are not authorized to create a folder in another user's home directory, if you don't have access for that.

Authentication factors

From a security point of view an authentication call be categorized in three ways, this can be based on what the person knows, something the person has, and finally something the person is. The three categories are:

Knowledge factors

A user has to know something in order to authenticate him e.g., a password, a pass phrase, a response to a security question. In your day to day routine you will frequently enter your email and password in somekind of form. Or if you are familiar with GIT, when you setup your ssh key it will ask you for a optional pass phrase.

Ownership factors

The user possess something to validate. If you ever worked in a coorporate environment you had your ID card, this has the purpose to confirm your identity. We can associate this in a web service with a security token, let's say you want to use an API from your favourite product, in many cases you may authenticate yourself using a security token, attachet to your requested URL or adding it to the request header (this may defer from provider to provider).

Inherence factors

In general inherence refers to a biometric identifier, such as a fingerprint or a signature. This factor may satisfy a multi-factor authentication. You can read more about inherence here.

Combining the factors. Two-factor authentication.

In order to achieve a multi-factor authentication approach, one must use two or more of the three independent authentication factors (describer above). To call it a successful authentication, each factor must be validated by the other party. In many cases when you want to login to your homebanking account you need to provide a password (knowledge factor) and security token from your digipass (ownership factor). Two factor authentication is not standardized, there are many process to choose from in order to achive it.

Thanks for reading, until the next time.

Why ?

Here are a few things why you should reconsider your strategy:

1. You’re relying on npm to serve you the same version of code compatible with your development including all sub-dependencies, because this might not be happening if the dependencies versions are not locked down, read more about npm shrinkwrap.

2. You’re 100% sure that npm or the online repository will always be available to server the exact packages you want, well it’s not always true.

3. You’re using it despite of npm advice of not using it:

   Use npm to manage dependencies in your dev environment, but not in your deployment scripts.

Your code is your responsibility!

Remember that your repository is the history of your development process, you should be able to roll-back to an older version if something goes wrong and everything should be working as before.

Minimize risk. Bad things can happen, but you better be prepared, you should not make yourself vulnerable to every little problem, try to solve them from the beginning and rise your defence.

Thanks for reading.

You can leave comments on hackernews.

The app is available on Github - please take a look for the full codebase.

As for this tutorial I will keep the back-end logic simple and write an API in node.js using Express 3.0 to query the Mongo location collection. There are a few things to cover so before starting might get handy to read through the official documentation

Let’s take a quick look on what we will cover:

• Setting up the API initial structure
• Defining the Schema for our collections
• Adding an index to our database
• Getting location(s) using our API

Setup

You should add the following dependencies to your package.json:

"dependencies": {
    "express": "3.5.0",
    "mongoose": "3.8.8",
    "async": "0.2.10"
}

• Mongoose is an ORM wrapper for talking to MongoDB.
• Express web application framework for node.
• async is an utility module.

Prepare the Mongoose

I am going to store location in Mongo, for this tutorial our location schema is going to be simple. This code assumes you have Mongo running on your local machine, with default settings.

Connecting to Mongo with Mongoose is simple:

mongoose.connect('mongodb://localhost/geospatial_db', function(err) {  
        if (err) throw err;

        // do something...
});

First we need to create a schema. The docs give us some examples on how to store geospatial data. We are going to use the legacy format for our example. It’s recommended to store the longitude and latitude in an array. The docs warn use about the order of the values, longitude comes first.

Note that you should always store longitude first!

var LocationSchema = new Schema({  
    name: String,
    loc: {
    type: [Number],  // [<longitude>, <latitude>]
    index: '2d'      // create the geospatial index
    }
});

Locations are going to have a name and a loc property. The loc is going to be an array holding the values for the coordinates [ , ]. Next we are going to tell Mongo to create a geospatial index for the loc. For this example we are going to use a 2d index, you can read more about index here.

Create a location object which we can use to query for specific locations.

// register the mongoose model
mongoose.model('Location', LocationSchema);  

Grabbing locations

First you can create a method in your controller that can look something like this:

findLocation: function(req, res, next) {  
    var limit = req.query.limit || 10;

    // get the max distance or set it to 8 kilometers
    var maxDistance = req.query.distance || 8;

    // we need to convert the distance to radians
    // the raduis of Earth is approximately 6371 kilometers
    maxDistance /= 6371;

    // get coordinates [ <longitude> , <latitude> ]
    var coords = [];
    coords[0] = req.query.longitude;
    coords[1] = req.query.latitude;

    // find a location
    Location.find({
      loc: {
        $near: coords,
        $maxDistance: maxDistance
      }
    }).limit(limit).exec(function(err, locations) {
      if (err) {
        return res.json(500, err);
      }

      res.json(200, locations);
    });
}

What this all means:

We are going to set a default 8 kilometers radius to search for locations within a set of coordinates:

// get the max distance or set it to 8 kilometers
var maxDistance = req.query.distance || 8;  

One important thing to note here is that our query will use radians for distance, so we need to transform our distance to radians.

distance to radians: divide the distance by the radius of the sphere (e.g. the Earth) in the same units as the distance measurement.

You should better follow up on this in the docs.

So to transform our distance to radians, we need to divide with 6371, the Earth’s radius approximately in kilometers.

// we need to convert the distance to radians
// the raduis of Earth is approximately 6371 kilometers
maxDistance /= 6371;  

Getting the coordinates in the right place:

// get coordinates [<longitude>,<latitude>]
var coords = [];  
coords[0] = req.query.longitude || 0;  
coords[1] = req.query.latitude || 0;  

Again: Note that longitude comes first!

Now for finding a location, we are going to use $near operator, which is going to return the closest location first. This operator sorts the returned objects from the nearest to the farthest. In combination with the $maxDistance operator, the results can be limited within a maximum distance to the specified point. Our query will look something like this:

// find a location
Location.find({  
    loc: {
        $near: coords,
        $maxDistance: maxDistance
    }
}).limit(limit).exec(function(err, locations) {
    if (err) {
        return res.json(500, err);
    }

    res.json(200, locations);
});

Having the full codebase we can test our small api by running this in the browser:

http://localhost:3000/api/locations?longitude=23.600800037384033&latitude=46.76758746952729

* the sample application contains a mock data source which loads some locations to you database bye default *

[
  {
    "name": "Piaţa Cipariu",
    "loc": [
      23.600800037384033,
      46.76758746952729
    ],
    "_id": "5335e5a7c39d60402849e38f",
    "__v": 0
  },
  {
    "name": "Stația Piața Cipariu",
    "loc": [
      23.601171912820668,
      46.76771454984428
    ],
    "_id": "5335e5a7c39d60402849e3a5",
    "__v": 0
  },
  ...
]

As you can see the server will return a list of existing locations for the specified point within the default max distance.

Mongo also supports the GeoJSON location data which is also a nice thing to check-out, there are a lots of interesting things related to the geospatial support, might be a good idea to read more about it in the docs.

Thank you for reading. Until next time.

You can leave comments on hackernews.

The app is available on Github - please follow the setup instruction to run it on your system.

Let’s take a simple flow for uploading an image for a user’s profile:

• User selects an image from the local disk.
• Image gets uploaded through a form.
• The application analyzes the data from the form and validates it. The image is uploaded to a temporary folder
• We move the image from a temporary folder to a permanent path.
• Respond with a success message to the user.

First, let’s discuss the front-end component - for this I will use EJS to create my form’s markup. We will create a simple upload form, nothing fancy.

<form action="/upload" method="post" enctype="multipart/form-data">  
  <label for="file">Select your image:</label>
  <input type="file" name="file" id="file" />
  <span class="hint">Supported files: jpg, jpeg, png.</span>
  <button type="submit">upload</button>
</form>

Now let’s get started with the application logic, we will start by defining our package.json file. You should add to your package.json the following dependencies:

"dependencies": {
    "express": "latest",
    "ejs": "latest",
    "uid2": "latest",
    "mime": "latest"
}

We are using Express as our web application framework, the default view engine will be EJS, in other words we are going to use EJS to create our views. I have used uid2 to create random names for the uploaded files. To determine the file type we can use mime, a practical little helper library.

Next step will be to create the app.js file, a starting point for the application, in larger applications a tend to name this file server.js and separate the app functionalities. I usually put my dependency and variable definition on top:

//Define variables & dependencies

var express = require('express');  
var app = express();  
var server = require('http').createServer(app);  
var controllers = require('./controllers');

Next I will configure Express to meet my requirements, first I will set the default engine as stated before we are using ejs, so we are going to compile the html files. Second, we are going to define a default place for the views. And last, we are going to tell Express that our view files are going to have the default extension .html.

//Configure Express

app.engine('.html', require('ejs').__express);  
app.set('views', __dirname + '/views');  
// Without this you would need to
// supply the extension to res.render()
// ex: res.render('users.html')
app.set('view engine', 'html');  

We are going to set up a pretty default configuration:

app.configure(function() {  
  app.use(express.bodyParser());
  app.use(express.methodOverride());
  app.use(express.static(__dirname + '/public'));
  app.use('/images', express.static(__dirname + '/writable'));
  app.use(app.router);
  app.engine('html', require('ejs').renderFile);
});

One thing to mention here is that I have used to static folders, one is /public where you can store your css and js files, and another one /images which will serve as our final path of the uploaded images. As you can see I am linking the /images route to a static folder /writable.

In order to access the upload functionality we are going to create two routes:

//Define routes
app.get('/', controllers.index);  
app.post('/upload', controllers.upload);  

The first / is going to serve us as our index route which will respond only to a GET request, and the second will be a POST on /upload path. As you can see I have separated the application logic into another file.

Finally we are going to start our server:

//Start the server
server.listen(3000, function() {  
  console.log("Express server up and running.");
});

The whole content of the file can be found here.

Initially I wanted to write all the application logic into a single file, but instead I separated it. I have created a new file called controller.js, first as usual I am going to declare my dependencies:

//Dependencies
var fs = require('fs');  
var path = require('path');  
var uid = require('uid2');  
var mime = require('mime');  

Also a good practice in order to define constants is to write them with capital letters to reflect their state so that their value’s should not be changed:

//Constants
var TARGET_PATH = path.resolve(__dirname, '../writable/');  
var IMAGE_TYPES = ['image/jpeg', 'image/png'];  

The TARGET_PATH is going to hold the final path of the uploaded images. In order to add some validation to file types, I have created an Array with accepted file types, in our case we are supporting only images.

To access the functionalities from controller.js file we need to export it, so that other files can use them. On easy way is to attach to the modules.exports ( or exports a shorter version ) what we want to export, in our case we are going to export a whole object:

module.exports = {  
  index: function(req, res, next) {
    // some logic
  },
  upload: function(req, res, next) {
    // some logic
  }
};

The index method is going to respond with the index.html file, so we are going to change it to something similar to this:

index: function(req, res, next) {  
    res.render('index');
},

Now the upload method is going to be a little bit more complex, as it has to deal with the upload functionality. You can access the uploaded files in the req variable’s files property in Express.

upload: function(req, res, next) {  
    var is;
    var os;
    var targetPath;
    var targetName;
    var tempPath = req.files.file.path;
    //get the mime type of the file
    var type = mime.lookup(req.files.file.path);
    //get the extension of the file
    var extension = req.files.file.path.split(/[. ]+/).pop();

    //check to see if we support the file type
    if (IMAGE_TYPES.indexOf(type) == -1) {
      return res.send(415, 'Supported image formats: jpeg, jpg, jpe, png.');
    }

    //create a new name for the image
    targetName = uid(22) + '.' + extension;

    //determine the new path to save the image
    targetPath = path.join(TARGET_PATH, targetName);

    //create a read stream in order to read the file
    is = fs.createReadStream(tempPath);

    //create a write stream in order to write the a new file
    os = fs.createWriteStream(targetPath);

    is.pipe(os);

    //handle error
    is.on('error', function() {
      if (err) {
        return res.send(500, 'Something went wrong');
      }
    });

    //if we are done moving the file
    is.on('end', function() {

      //delete file from temp folder
      fs.unlink(tempPath, function(err) {
        if (err) {
          return res.send(500, 'Something went wrong');
        }

        //send something nice to user
        res.render('image', {
          name: targetName,
          type: type,
          extension: extension
        });

      });//#end - unlink
    });//#end - on.end
  }

Breaking down the method:

We need to get the type of the file in order to validate it, we also need to store the extension of the file, later we will use the extension when renaming the file.

//get the mime type of the file
var type = mime.lookup(req.files.file.path);  
//get the extenstion of the file
var extension = req.files.file.path.split(/[. ]+/).pop();

//check to see if we support the file type
if (IMAGE_TYPES.indexOf(type) == -1) {  
    return res.send(415, 'Supported image formats: jpeg, jpg, jpe, png.');
}

Create a new name for the file, remember we added uid2 to dependencies, we are going to use the uid() function in order to create a new random name for our file and concatenate the extracted extension.

targetName = uid(22) + '.' + extension;  

There are a few approaches regarding the moving of the file from a temporary place to a permanent place. One of the is to use fs.rename():

fs.rename(tmpPath, targetPath, function(err) {  
    if (err) throw err;
    console.log('Done.');
});

This is pretty simple but, normally /tmp is in tmpfs, in ram and you cannot directly rename two files from different devices, it gives EXDEV error. Instead of using this method, I have created a read and write stream in order to accomplish the copy to a different path functionality.

//determine the new path to save the image
targetPath = path.join(TARGET_PATH, targetName);

//create a read stream in order to read the file
is = fs.createReadStream(tempPath);

//create a write stream in order to write the a new file
os = fs.createWriteStream(targetPath);

is.pipe(os);  

When the stream is done it will dispatch an end event to which we can attach our own callback:

//if we are done moving the file
is.on('end', function() {

    //delete file from temp folder
    fs.unlink(tempPath, function(err) {
        if (err) {
        return res.send(500, 'Something went wrong');
        }

        //send something nice to user
        res.render('image', {
            name: targetName,
            type: type,
            extension: extension
        });

    });//#end - unlink
});//#end - on.end

A good practice is to delete your temporary uploaded file after you moved it, for this we are going to use fs.unlink(), if everything goes well we can send a message to the user that the file has been successfully uploaded.

There is a lot more work that can be done here - especially when it comes to event handling and validation. A future improvement that I would like to add is to show a nice progress of the uploading to the user.

Thank you for reading. I hope you have found some useful information in this article. Until next time.

You can leave comments on hackernews.