Category Archives: Development

Guided Description Forms

Today’s blog post moves a bit away from my current trend in Node.js server side code and moves on to a UX/UI problem that I solved recently.

The problem

You have a description field – just a text/html wysiwyg field that the user is supposed to fill out. The problem is that for whatever reason you want the user to add specific data to the field or in a specific format and our users are not very good at following instructions as we all know! Now you could just pre-populate the field with some titles and blanks for them to fill out, but this isn’t very “nice” to use. I came up with the following solution (cause running code is worth more than the proverbial 10,000 words):


This code runs around 2 main directives called: ‘dynamicInput’ and ‘formDescription’. Pretty simple, the former takes in some options that change how it is displayed, the latter watches all the fields passed into it to update one ng-model with the compiled code.

Hope this helps out someone else, if you have any comments/improvements or use this in some cool app – Please let me know in the comments!!

Node Routes with Functional Programming

Today’s post is a little short and a little late as I’m pretty busy at work!

I’m going to do a quick functional programming example that I do in my routing of my application, now there probably is an easier way, but as allways programming is a process.

Here’s the code:

_boolHandle = (_f) -> (req, res) ->
  _testExists req.params.ticketID, res, -></pre>
    _f req, res, (err, results) -> if err then res.status(500).json err else res.status(200).json results or true '/api/ticket/:ticketID/metadata', _boolHandle (req, res, cb) -> $tickets.metadata req.params.ticketID, req.body, cb

This is essentially a post handler in express 4 that calls a function that returns a function to call a function to call a standard response!

If we break it down, when we register the handler, normally this would be written as follows: '/api/ticket/:ticketID/metadata', (req, res) -> res.status(200).json true

My first step was figuring out that every call I made to the $ticket object calls it’s callback with (err, result) and returned the results, so my code then looks like this: '/api/ticket/:ticketID/metadata', (req, res) -> $ticket.metadata req.params.ticketID, (err, result) -> if err then res.status(500).json err else res.status(200).json result

Because I’m lazy I decided I didn’t want to write out the callback every time, it’s always the same so why bother? So my first functional programming block was this:

_boolHandle = (_f) -> (req, res) ->
  _f req, res, (err, results) -> if err then res.status(500).json err else res.status(200).json results or true '/api/ticket/:ticketID/metadata', _boolHandle (req, res, cb) -> $tickets.metadata req.params.ticketID, cb

As you can see I abstracted out the response by creating a wrapper around it. The other part I have in the code is the function that tests whether the ticketID actually exists (_testExists), if it exists it calls the callback else it returns a “ticket not found” error.

I hope this explanation helps someone out, if you have a better way of doing this – I’m all ears!!

Node.js As a Service on Windows

This week I am going to outline the difficulties I have in getting my app running as a service on windows.

Normally I would start up my server either by calling “coffee” or “npm start”. If you look around at the blogs and posts about this you’ll find that all of them refer to running the service via “node app.js”. Which just plain won’t work for me.

Beforehand I’ve used nssm, so I decided to give it a go again, I settled for getting it to run “npm start”.


  1. Figure out the location of your node.js installation (node.exe), for me it was “C:\Program Files\nodejs\node.exe”.
  2. Fire up nssm in the add service mode.
  3. Enter in your node installation for Application Path.
  4. Enter in the directory of your project in Startup directory.
  5. In Arguments put in the quoted location of the npm-cli.js file and then “start” (with quotes). This should be relative to your node installation, for me it’s “C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js”.
    In total the Arguments field should look like:

    "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "start"
  6. Hit save and your service should run as if you called “npm start”!


CRM Migration (Part 2)

Part One

Continuing on my series on gradual migration from Coldfusion to Node-js today I’ll be writing up about the authentication system that allows me to have one login that tells both node and coldfusion that the user is authenticated. (Sorry about all the &gt; showing up everywhere – Can’t figure out how to get rid of them)


Having worked my way through many iterations of this code, I’m going to start with a quick rundown of the process it took me to get to the end result.

  1. “I can just proxy through all requests to the CF Server, that sends the cookies as well.” Good points of this is that there’s a node module for that (isn’t there always!), bad point is that if you want to have node communicate with coldfusion as well, for example sockets that call logic on CF, you can’t use the cookie from the CF Server if it’s set up correctly to prevent cookie jacking. So this was a no go as essentially I ended up with 3 sessions, Browser to CF, Browser to Nodejs and Nodejs to CF, not good!!
  2. “OK, so if I write my own proxy code I can control the cookie right?”. Well, not quite though we’re getting there, again with the same origin restriction on cookies this didn’t work so well.
  3. “Right, so I have to have all communication with CF sent via node and not store the CF cookie on the browser.” This is about right!

How It’s Done

So if you remember last week there was a function and variable I said I’d explain this week, testCookie and req.session.proxyCookie? Well both of those are to do with my authentication solution.

We start off with the basic cookie and session setup for node:

@use cookieParser security.cookieSecret
 @use session
    httpOnly: true
    secure: false
    maxAge: 3600000 * 8 # hour in ms * 8 = 8 hours
  secret: security.cookieSecret
  store: sessionstore
  saveUninitialized: true
  resave: true

Here we’re using a couchbase memcached session store to store our cookies with some extra settings.

Next we have three functions for working with the Cookies these are:

parseCookie = (cookie) -&gt;
 _cookie = request.jar()
 if cookie? then _cookie.setCookie require('tough-cookie').Cookie.parse(_c), security.proxyAddress for _c in cookie
testProxyCookie = (session) -&gt;
   _foundCFID = false
   for key, cookie of parseCookie(session.proxyCookie)[security.proxyCookieDomain]['/']
     if key.toLowerCase() is 'cfid' and cookie.value then _foundCFID = true
     cookie.lastAccessed = new Date().toISOString()
   return _foundCFID
   return false
@testCookie = (req, resp, cb, isLogin=false) =&gt;
  if req.session? and (not testProxyCookie(req.session) or isLogin) and resp.headers and resp.headers['set-cookie']
    req.session.proxyCookie = request.jar()
    req.session.proxyCookie resp.headers['set-cookie']
    @getSessionCookie req, (sidCookie) -&gt;
    sessionstore.set sidCookie, req.session, cb
  else cb()

@getSessionCookie = (req, cb) -&gt;
  cookieParser(security.cookieSecret) req, {}, (parseErr) -&gt;
  if parseErr then return next new Error 'Error parsing cookies.'
  # Get the SID cookie
  EXPRESS_SID_KEY = 'connect.sid'
  cb (req.secureCookies and req.secureCookies[EXPRESS_SID_KEY]) or
     (req.signedCookies and req.signedCookies[EXPRESS_SID_KEY]) or
     (req.cookies and req.cookies[EXPRESS_SID_KEY]), sessionstore

@sessionAuth = (req, res, next) =&gt;
  @getSessionCookie req, (sidCookie) =&gt;
    req.sessionroomid = sidCookie
    if testProxyCookie req.session then next()
    else request
      uri: "#{security.proxyAddress}index.cfm/users/nodetestlogin.json"
      method: 'GET'
    , (err, resp, data) =&gt; @testCookie req, resp, next, true
@all '*', @sessionAuth

Let’s Break it Down!!

So, to start off when a user hits a page, the `@all ‘*’, @sessionAuth` gets hit. this in turn calls the `getSessionCookie` which if you haven’t guessed loads the cookies sent to node and finds the ‘connect.sid’ cookie value. We then store this cookie value in the request as the req.sessionroomid which we’ll use later for sockets and updating just one client across all his tabs (I think this may be a security hole but I’m yet to go back and review it yet). Then we call `testProxyCookie`, this function does two important things, first, it checks that the cookie we have stored in the session for communicating with CF is valid, and second it updates the lastAccessed value. Updating the lastAccessed value is important as when you send the cookie through CF uses this to detect if your session should have timed out yet or not! If you don’t update this and have say a 30 minute session timeout on CF, then even if you keep contacting CF constantly, 30 minutes after your first contact your session will expire!! Back in `sessionAuth` if the proxy cookie is valid (`testProxyCookie()` returns true) then we continue via `next()`, if not we send a request to the CF server using request and then use `@testCookie` to set the proxyCookie from the result.

In short `@testCookie` reads the response from the CF Server, parses the cookies and then saves the value in the session value, we later use that cookie with request to authenticate to the CF Server. Beyond the above you can setup your node.js server as you normally would and this will take care of all the integration.

Till Next Time (Which I am yet to decide what I’ll write about!).


I found a nasty bug that runs around the storage of tough-cookie objects – basically it doesn’t work! My solution was to store the ‘set-cookie’ headers instead and then add a ‘parseCookie’ method to convert it into the actual cookie jar object. This means that when you make the call to the CF server you do the following:

  uri: "#{security.proxyAddress}/index.cfm"
  method: 'GET'
  jar: parseCookie req.session.proxyCookie
, (err, resp, data) =&gt; #handle response here!


CRM Migration (Part 1)

Recently I’ve been able to start moving our internal Coldfusion based CRM onto Node.js, I’m going to start chronicling the difficulties and challenges this has produced and my solutions to these problems in this multi-part series CRM Migration. My aim is to get one of these up every wednesday.


The first problem I came across is the nastiest one for a partial migration; How do I keep one login for both sites?

To solve this we need to solve a simpler question – How do I access legacy coldfusion pages that we aren’t migrating yet?

I tried using node-proxy, but that didn’t go so well after a while due to cookies making sessions do weird things, my eventual solution was as follows:

@get '/index.cfm*', (req,res) ->
		uri: "#{security.proxyAddress}#{req.url.substring 1}"
		method: 'GET'
		jar: req.session.proxyCookie
	, (err, resp, data) => testCookie req, resp, -> res.send resp.statusCode, resp.body
@post '/index.cfm*', (req,res) ->
		uri: "#{security.proxyAddress}#{req.url.substring 1}"
		method: 'POST'
		jar: req.session.proxyCookie
	, (err, resp, data) => testCookie req, resp, -> res.send resp.statusCode, resp.body

NOTE: I started off using zappajs, but then migrated to Express 4 so I replicated the helpers. The ‘@’ is essentially a reference to the express server variable.

I’ll start by explaining the reasoning behind the URL structure; ‘/index.cfm*’. The CRM in coldfusion runs on CFWheels, a MVC library, and I never got the url rewrites to work on IIS so an example format for Coldfusion URL’s is ‘/index.cfm/{controller}/{action}/{key}’. The two above handlers basically state that any request that starts with ‘/index.cfm’ is targeted to the coldfusion server, in case you haven’t guessed my approach is to field ALL http requests to the node.js server which will act as a proxy for the Coldfusion server if we haven’t migrated that across using node.js’s built in request library.

That’s basically it for access to the old Coldfusion pages, you may be curious about the ‘testCookie’ function and where on earth this ‘req.session.proxyCookie’ variable comes from, but that will be in Part 2.

Hint: It’s about authenticating the user for node.js and coldfusion!

See you all next week!

If you want to know about my basic setup for Node.js projects with express see my Nodejs Website Base. oEmbed of codepen’s

To celebrate wordpress’s addition of allowing us to embed codepen’s into our posts I am going through my posts and moving all my examples and demos over to codepen and embedding them in my blog posts.

I’ll post a list of the posts as I do them here (with embed’s here as well!):

Progress Bar as Submit Button

Bootstrap and Affixed Nav for Mobile

Securing Express Routes with PassportJS

It’s been a while since I posted anything, but I finally found something worth blogging about! Besides my trip to India at the beginning of the year and not much work recently…

Recently I’ve been building a web app for my gaming clan to help them run their practices and also to help me learn more of Node.js and NOSQL (CouchDB in particular). My first big problem in building this app was that of user login, or authentication. After googling around a bit for some modules to help with this (I really like the modular nature of node.js!) I came across a unified login system called Auth0, which I have to say is really awesome. I decided to go with this as who hasn’t thought that letting people login using facebook or similar would be cool but it’s too hard to bother! After running through their node.js tutorial which makes use of PassportJS and their authentication strategy passport-auth0 I came up with the following basic login/authentication code. (This is stripped down a bit, for my full code see here)

http = require 'http'
express = require "express" # Note this is Express v3.5.x

app = module.exports = express()

httpServer = http.createServer app

passport = require 'passport'
Auth0Strategy = require 'passport-auth0'
security = require('./security')

strategy = new Auth0Strategy 
	domain:       security.auth0.domain
	clientID:     security.auth0.clientID
	clientSecret: security.auth0.clientSecret
	callbackURL:  '/callback'
, (accessToken, refreshToken, profile, done) ->
	console.log "Hit Auth0 strategy"
	done null, profile

passport.use strategy

# This is not a best practice, but we want to keep things simple for now
passport.serializeUser (user, done) -> done null, user

passport.deserializeUser (user, done) -> done null, user

helmet = require 'helmet'
app.configure ->
	app.use express.logger 'dev'
	app.set 'views', "#{__dirname}/views"
	app.engine 'jade', require('consolidate').jade
	app.set 'view engine', 'jade'
	app.use helmet.xframe(), helmet.iexss(), helmet.contentTypeOptions(), helmet.cacheControl()
	app.use express.json(), express.urlencoded()
	app.use express.methodOverride()
	app.use express.cookieParser()
	app.use express.session
		secret: security.cookieSecret
			#httpOnly: true
			# secure: true # for HTTPS only
	app.use passport.initialize()
	app.use passport.session()
	app.use require('express-validator')()
app.all '/api/*', auth

auth = (req, res, next) -> if req.isAuthenticated() then next() else res.redirect '/login'

# Auth0 callback handler
app.get '/callback', passport.authenticate('auth0',
	failureRedirect: '/login'
), (req, res) ->
	if not req.user then throw new Error 'user null'
	if req.user._json.appid?
		req.session.dbconn = require('./../startup_security/nano').nano req.user._json.user_id, req.user._json.dbpass
		res.redirect "/#{req.user._json.appid}/manage"
	else res.redirect "/first-login"

# warning this would log you out of facebook if you logged in via the facebook button - don't use this in live!
app.get '/logout', (req, res) ->
	delete req.session
	delete req.user
	res.redirect ""

app.get '/login', (req, res) -> res.render 'login.jade'
app.get '/first-login', auth, (req, res) -> res.render 'first-login.jade'

httpServer.listen 3000

console.log "Server Running on port 3000 via ExpressJS"
console.log "Authentication Via Passport.js and Auth0"

Now this is my final code after some help from the owner of passport-node0 here. Now I’ll detail some of the quirks I had to get through that are really, really poorly documented.

First; Authenticating individual routes. Initially from reading through what other people have written and the other information out there I tried this:

<pre>app.get '/first-login', passport.authenticate('auth0'), (req, res) -> res.render 'first-login.jade'</pre>

That is WRONG, and meant I spent many many hours looking at 302 redirects from that page back to the login page for no discernable reason…
Correct is:

auth = (req, res, next) -> if req.isAuthenticated() then next() else res.redirect '/login'</pre>
<pre>app.get '/first-login', auth, (req, res) -> res.render 'first-login.jade'</pre>

Secondly; Authenticating all routes matching a particular prefix. From here and there around the web I thought you did this via:

app.use '/api', auth

Turns out that’s also wrong (this ones in the docs so I felt really stupid when I found it). Here’s the correct one:

app.all '/api/*', auth


I’d like to introduce you all to a project I have been contributing to recently. It is called textAngular. It is a WYSIWYG editor designed from the ground up to work in AngularJS with no external libraries and, thanks to document.execCommand, no IFrames either!

We’ve recently released version 1.1.2 and I highly recommend that you check it out if you work with AngularJS in any way.
Check out the GitHub page for the Wiki and Source code:

Railo after Upgrading to OSX Mavericks

Recently I upgraded my MacBook pro to OSX Mavericks (10.9). Almost everything worked nicely until I tried to open a development page I serve using Tomcat-Railo (3.3.1 I think) and I got nothing…

So without further preamble I am going to chronicle my problems and their solutions in a few short steps to get you going with Railo on OSX Mavericks. NOTE: these instructions are if you use the OS’s inbuilt JVM, if you use a bundled JVM you probably only need to follow Step 1 and 3.

The default place of {Railo Home} is /Library/Railo/.

Step 1


No seriously – it’s not all that bad, you don’t need to upgrade/reinstall anything. Then Shutdown Railo using {Railo Home}/connector/, just to be safe (it probably isn’t running anyway).

Step 2

Install Java – any variant should do (or did for me). The issue here is that Mavericks uninstalls all your previous versions of Java quite happily and without letting you know. I installed the latest jdk which was Java Platform (JDK) 7u45.

This should then install to /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/

Step 3

Fix apache – see this blog post here:

Step 4

Change/Add the script to tell railo/tomcat where java is. You find this file at {Railo Installation}/tomcat/bin/. Mine reads as follows:

<br />JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home<br />PATH=$PATH:$JAVA_HOME/bin<br />CLASSPATH=$CLASSPATH:$JAVA_HOME/lib<br />

Step 5

Start Railo using {Railo Home}/connector/

Your sites should be working again!

Bootstrap and Affixed Nav for mobile.

Recently I have been working on a new website for my primary contract referrer, I decided to use Bootstrap 3.0 as my base and as an absolute necessity it should look nice on all platforms (even mobile). Note that I am part of this group that doesn’t believe that it should look the same on all browsers, platforms and screens, just that it looks nice.

My first issue was quite interesting as I found that my wonderful iPhone’s default browser doesn’t support position: fixed (See for more detail on this). This means that my nice affix plugin using navbar only worked on normal browsers and not on my iPhone. This I decided was not an acceptable solution, so I started googling, then I googled some more and came up fairly blank. Yes there were a couple of bit’s and pieces here and there that hinted it could be done, but nothing that hit all the targets of: Bootstrap 3.0 Affix Navbar.
So cobbling together some other answers I came up with this: (or for without the code frames).

Once you’ve had a look at the example keep reading for the full breakdown.


The concept is a combination of the affix plugin as it works normally, and on mobile (in this case smaller screens) we work around the position: fixed by absolutely positioning the navbar at the top all the time. Now this isn’t a perfect solution – I just didn’t want to use more javascript than necessary. You will notice that in the mobile version we do not affix to top when it scrolls down – it is always pinned to the top. My reasoning for this is that though it’s fine for a desktop site to show the menu only later when you’ve scrolled down, as a usability point I find that if I’m using a mobile it’s not to look at the pretty pictures – hence the most important thing on a mobile is navigation around the site. We put our contact us button in the menu so it’s easy to see and click all the time.


The demo has 2 main parts to it – the <header> and the <div id=”scroll-wrap”> parts. The HTML is basic, nothing fancy to see there we just place the header element then all our content inside the scroll-wrap element. In the CSS is where the fun starts. As you probably have heard – it’s a bad idea to try change how things are done via browser sniffing as IE 11 for one has started lying about what it is! So to embrace this I design my sites using modernizr and for size of screen rather than type of screen. On smaller screens – to target the iPhones in particular I use media queries to absolutely position the header and then the scroll-wrap for the remaining viewport area. We then use overflow: scroll to make this the scrollable area (Note the use of  -webkit-overflow-scrolling: touch this means the div scrolls nicely on my iPhone). Nice thing about this approach is that the menu stays “Fixed” at the top. If you are using this method do keep in mind that the screen is small – the bigger your fixed area the smaller the screen to read on I’d recommend not using up more than 10-15% of the screen height with fixed elements especially if you set user-scalable to no.

Last Words

Another thing I haven’t demoed here is using bootstraps scrollspy in this situation – a simple solution is to initialise it twice:  $(‘body’).scrollspy(); $(‘#scroll-wrap’).scrollspy();. Though not perfect it does get the effect to work as only one scroll event will fire depending on how the CSS has changed the scroll-wrap.

Admittedly this won’t suit everyone and for some if you are fine with an always absolutely positioned navbar (or similar) on smaller devices you won’t need any of this. For those of those it helps – do leave a message, it’s nice to know the views aren’t all spam-bots!!

Reference: For why browser detection is bad: