huboard.com!

Your favorite open source kanban board built on top of the GitHub api has gotten a little bit more awesome. I’ve decided to release the socket.io backend that is keeping huboard.com all up to date and super fancy.

Why nodejs (express + socket.io)?

1. Simple

Nodejs (express + socket.io) was by far the easiest thing for me to get running on heroku. The original version I published back in August was only about 26 lines of javascript.

2. Reliable

I’m absolutely amazed, I pushed that code up to heroku back in August and haven’t touched it. It ran for about 6 months and I never even checked on it. As far as I can tell it never even crashed.

3. Documentation

There is a ton of great tutorials and blog posts just a google search away on getting socket.io up and running on heroku.

• Heroku – Dev Center
• Socket.io site

4. Cheap (free as in beer)

Plain vanilla install of socket.io and express configured to use xhr-polling has been running problem free on heroku with one free dyno for 6 months. I’m not exactly sure how far that will scale using the MemoryStore (eventually I’ll run out of RAM) but huboard is sitting at nearly 4000 users and haven’t had any problems yet

Other options

I did explore other options

• .NET – server sent events – (fubumvc or signalr)

  • FubuMVC.ServerSentEvents
    • Not supported by heroku (see #1 && #4)
    • SSE only – no fallback support
    • Very little documentation
  • [SignalR]
    • Not supported by heroku
    • Not as stable (at the time)

• Ruby – EventMachine

  • I originally wanted to use something simple on top of ruby. I tried several different approaches and ultimately I just couldn’t figure out how to host a HTTP POST endpoint && the socket connections inside the same app.

Why did it take you so long to release it?

Well the TL;DR; is that it wasn’t secure. It was largely experimental. Back when I published the RealTime™ support the socket.io server was only about 26 lines of nodejs. It had no security because I didn’t know how to set it up. So I secure it the best I could (with a simple correlation string) and called it a day. The code wasn’t published so hackers at least had a harder time connecting to the socket than if the code was in the open. Security by obscurity (I know shame on me, I’m sorry).

How are you going to make it secure?

Step one is open sourcing it, people who are using huboard and know more than I do will hopefully care enough to help me make it as secure as possible.

• Things I’m doing already.

All my users trust me with their OAuth token and I take that responsibility seriously. I try my best to make sure your authorization key doesn’t get into the wrong hands. Huboard never exposes your authorization key unencrypted.

The socket server now performs a handshake when making a connection. Your encrypted OAuth token is passed into socket.io via query string, which turns around and passes the encrypted key to a huboard api endpoint that decrypts your token and asks the GitHub api if its valid.