Calling a web service (.net) from node.js

Took me a little experimentation (given the number of bad examples posted online) to figure this one out but I needed to authenticate a users token through the listener running in node (5.0.0).

I setup the token.js file to use with the following

 var app = require('express')(),
     http = require('http').Server(app),
     io = require('')(http),
     tokens = [];

Inside of the connection method I created a listener for the ‘register’ message that called the .NET web service to verify the authentication token. This code will be shifted to use the tedious framework in the near future. I included lodash to quickly check to see if the token is in the local array or if not, add it.

  socket.on('register', function (token) {
    var request = require('request');{
      url: 'http://xxx/authentication.asmx/VerifyToken',
      method: 'POST',
      headers: { 'Content-Type': 'application/json; charset=utf-8' },
      body: JSON.stringify({ token: token })
    function (err, resp, msg) {
      var body = JSON.parse(resp.body), t = JSON.parse(body.d);
      if (1 == t.flag) {
        var _ = require('lodash'), l = _.indexOf(tokens, token);
        if (l == -1) { tokens.push({ token: token, id: }); }
        socket.broadcast.emit('token', true);
      else {
        console.log('Invalid Token/Socket ID ' + + ' Token ' + token.substring(0, 15));
        socket.broadcast.emit('token', false);
  }); // register

Client side, once logged in, it’s as simple as passing:

 socket.on('connect', function () { socket.emit('register', user.token() });

And providing a callback listener that will check for ‘token’ coming back with a true/false. This way the administrator can void the authentication tickets server side and the client will automatically be notified their tokens are no longer valid and sent back to the login screen.

Testing Backups…

When the call comes in that there was an explosion in the building is not the time to ask “is all of our data backed up?” This just happened and reinforces my methodology of testing backups on a routine basis.

If you are backing up your data but not testing the backups by restoring data, volumes or virtual machines, then no, you cannot say you have a working backup. It’s the same as having batteries in the flashlight only to find a pool of acid in the handle when you open it after the lights have gone out from the batteries leaking.

Depending on your volume, at a minimum of once a month, you should restore from multiple points to test your backups. If your backup system supports multiple delta-points, pick the oldest you can find and restore those.

  • Restore entire virtual machines into your lab and fire them up to make sure they work.
  • Restore Exchange databases to your lab and make sure Exchange Server can mount them.
  • Restore SQL databases to make sure the account credentials were also stored so you don’t have to reassign logins.

In short, backup, backup, backup and then restore or don’t be surprised if you get a pool of acid in the flashlight handle when the lights go out.