using passport for facebook authentication

passport and passport-facebook offers very easy facebook authentication integration into your node app. for the most part, it’s very straightforward, but i got tripped up in a few places.

i’m using krakenjs for my express framework so you have to be a little mindful that some of the express setup stuff has been abstracted away from you. because of that, i was puzzled because i didn’t understand why i couldn’t get access to the passport user object once authenticated.

passport wants to uses sessions. make sure that you enable the express session middleware and make sure you use the middleware before trying to use passport. order matters here. additionally, if you are using cluster, you can’t use in-memory sessions, you’ll have to use something that is globally accessible by all node processes…something like redis can be used via connect-redis.

passport extends express’ req with the isAuthenticated() method
i initially thought that i had to implement and check whether or not the user is authenticated, but passport handles this for you.

you have to implement passport.serializeUser() and passport.deserializeUser()
passport.serializeUser() is the function that will serialize the user info into the session, typically the user ID. at this point, you have access to the Facebook profile object, so you have information like: facebook user ID, username, displayName, etc.

This function is run once at time of authentication to put the authenticated user into the session.

passport.deserializeUser() is the function that will take the user ID from the session then construct the full information of the user and then make this object available in req.user. this function is run on every request to construct the req.user object so make sure that this code is performant. documentation everywhere says that this is where you would query a database to get user information, but it seems like involving a caching layer here would be advised.

my biggest pet peeve: unlinted javascript/node code

the world of front end development is rapidly changing and with the popularity of node.js, it seems that javascript is creeping up everywhere. one of the misconceptions about javascript is that it is a hacky language by nature and the code is always going to look hacky. another popular misconception is that because javascript is executed in the browser and best practice is to minify your javascript code, it doesn’t matter about maintaining a consistent style within your javascript. sadly, many front end developers believe this and it is these same front end developers who are now experimenting with node.js and writing crappy server side code.

the really sad thing here is that there are amazing tools available that solves this problem. as far as i’m concerned it is a solved problem, the barrier to adoption is very low, and there is no reason not to have style adherence in your code base. what i’m talking about here are static code analysis tools for javascript. these are tools that will analyze your code and tell you where there are potential code smells.

there are two that i use for javascript development: jshint and the google closure linter.

two seems like it may be a little overkill and though both tools do have some amount of overlap, they serve two different purposes for me.

for me, i use jshint to detect errors and potential problems in my code. i prefer jshint over jslint because it is a little less opinionated (or can be configured to be less opinionated) than jslint. jshint is a good tool to find problems in your code, but it also helps with writing code with best practices.

google closure linter
google closure linter does the same things jshint does, but it also enforce style conventions. this is amazing by itself, but google has gone one step further and they bundled a tool called fixjsstyle with their gjslint app. fixjsstyle will try to fix all of the problems that gjslint finds. this blew my mind. this tool makes style adherence insanely easy. there is no longer any excuse not to conform to the same style…and yes, it is google’s style convention, but i happen to agree with most of what they say.

so great, there are two tools that lints your code for you, but wait, there’s more!

it seems that javascript developers are all gravitating towards using sublime text editor as their IDE. there are two plugins that will lint your code in real-time so that you will never have to run your linters outside of your text editor: SublimeLinter and JSHint Gutter.

so how do you go about doing it? if you’re on a mac/linux system, you do:

Install jshint and create soft link

Install gjslint and create soft link

Install Sublimt JSHint Gutter plugin
In Sublime Text: Command-Shift P, Package Control: Install Package
JSHint Gutter
You can optionally configure Sublime to lint on edit or save:

Install SublimeLinter
In Sublime Text: Command-Shift P, Package Control: Install Package
Configure SublimeLinter to use Google Closure Linter

Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – Default
Copy the entire file that has been opened here

Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – User
Paste contents into this file
Make the following edits:
“sublimelinter_gutter_marks”: true,
“sublimelinter_mark_style”: “none”,
“javascript_linter”: “gjslint”,
“gjslint_options”: [],
110, // line too long
220 // jsdoc supression

setting up SSL for node using express

i’ve been working with node a lot lately and i’m surprised that i haven’t needed to do this sooner, but i finally needed to set up SSL for one of my node apps and it wasn’t hard to do, but there was no one place where all of the steps were documented on how to setup SSL using express. it actually is pretty straightforward and easy.

first you need to create a certificate for SSL. this can be done by using the command line tool: openssl.

once you have the certificate, all you have to do is tell node that you want to use the certificate you made for the SSL requests. what i didn’t know, but is actually very clearly documented in express’ api documentation is that the variable “app” returned by express() is actually a function used as a callback for node’s http to handle requests. so instead of starting up your server via an app.listen() call, you can simply go back to the basics and use node’s http and https APIs to start the server and pass express’ app to it.

if you want the same code to handle both http and https requests, you can simply call http and https’ createServer() method on different ports.

how to test IE 6/7/8/9/10/11 on a mac

web development these days is great fun. there are many frameworks that help deal with all of the various browser quirks out there, but the only real true test to make sure that your site works in various flavors of internet explorer is still to run the actual version of internet explorer. sure, the browser mode setting does a pretty good job of getting things right and gives you access to some better developer tools, but sometimes you just need to see it in the native browser.

now suppose that you are developing on a pc and you have one version of internet explorer installed, but what about all of the other versions? traditionally, you’d have to set up virtualpc and make several VMs.

the situation gets more grim when you develop on a mac and don’t really have windows machines available to you. what do you do then what you do is run xdissent’s amazing ievms script which will download, setup, and snapshot VMs for IE6/7/8/9/10/11 right there on your local machine. you’re going to need a lot of hard drive space to install VMs for all of those browsers, but it is quite the handy script.

check it out:

visual event 2

ever wanted to see what are all the attached event listeners on a page? if the events were attached using some of the popular javascript libraries, there’s a cool little bookmarklet that will show you visually what parts of your page have event listeners bound to them.

3995 days ago 30 Comments PERMALINK

debugging node with

i’ve been using for a little while now on my code projects and i’ve had a few thoughts. first and foremost, what delivers what is promises by giving you a very visual representation of every single line of code executed in real-time. i’ve had hit or miss success with it debugging a non-trivial express-based project. the most common culprit is that appears to consume all of the memory available and just dies a horrible death. i’ve had some other minor issues with the browser crashing out on me as well.

so far, my go to debugging method is still using node-inspector, but hints at some great potential. i’m trying to use it more and see if i can incorporate it in my debug workflow, but the amount of code that it rips through is impressive and daunting at the same time. still, it’s a steal (well, for commercial software, anyway) at $15 and is definitely worth a look.

nock – the web service mocking node module

I have recently started to develop a node project where I am promised that all of the information that I will need to render a page will be exposed via API calls. This is fantastic because it significantly simplifies my development as it is easy to call a bunch of services and manipulate data.

The problem is that the services that I am promised to develop my project have not been created yet. Worse yet, the delivery of these services look like it may be weeks from now, but I need to start my development on the front end side of things now!

We’re using node to power our web server, specifically the express web framework and so it seemed only natural to be able to mock our web services within node. Ideally, I should be able to swap my mocked services with the real services in a relatively painless fashion (via a configuration parameter, perhaps?)

flatiron’s offering of nock seems like a brilliant idea. What it does is intercept every HTTP request to a given endpoint and returns your mocked response instead. That, alone, makes nock pretty cool. But wait! There’s more!

nock also provides a way to record any http request and then save the response as a nock mocked object. You just turn on the recorder, make your http request, and then you will have all the code necessary to “nock” it out.

That’s AH-MAZ-ING!

Integrating JavaScript linters in Jenkins

I use two linters to lint my JavaScript: JSHint and Google Closure Linter. I use JSHint primarily to check for JavaScript code best practices and rely on Google Closure Linter for style convention enforcement. This combination of linters is run in real time for me via the SublimeLinter package in Sublime Text Editor.

Usually that leads to pretty clean code for me, but for others who contribute to the project, I needed to make sure that their code passed the same tests. It turns out that I haven’t found a good solution for integrating JSHint and the Closure linter into Jenkins.

I’ve decided for now to just run them as build steps that run command line programs, but surely there must be a better way. Isn’t there?

Getting the output of these tools to be picked up by the Violations plugin in Jenkins isn’t terribly difficult, there’s some massaging of the output needed for the Closure linter, but luckily JSHint exports it in a Violations-friendly format.

It took me about 15 minutes to figure out how to run jshint recursively.

Of course, it was that easy.