stormpath node api

sample.js

var app = require('express')();
var stormpath = require('express-stormpath');

// example 1 - auth by middleware
app.use(stormpath({
    '/', true,      // enforce login
}));

app.get('/', function(req, res) {
    res.send('im authenticated!');
});

// example 2 - auth by explicitness
app.use(stormpath());

app.get('/', function(req, res) {
    stormpath.login_required(); // enforce login
    res.send('im authenticated!');
});

// example 3 - auth by kinda explicitness
app.use(stormpath());

app.get('/', stormpath.login_required(function (req, res) {
    res.send('im authenticated!');
}));

I think it would be helpful to define the use cases, of which I see two:

• "I don't really care to customize this, it's a new app, I'll do what you tell me" - in which case I'd so something like app.use(stormpath.default()) - which will register a global middleware which does your self-proclaimed magic by inspecting all incoming requests and doing the right thing.
• "I want to use this on just some routes"

And both could totally be supported by the same module

The implementation of the first use case is totally up to you and you can modify the solution over time via feedback from developers. You can give the developer some options to be passed into default({}), such as: what is the route for the login page? what do i do when someone isn't logged in but needs to be (do i send them to /login, or just show an access denied page? etc). In this situation you will be defining a lot of application behaviour and UX for the user, at which point it's become more than middleware, in my opinion

The latter should be more of a pure middleware situation, meaning: implement a function that does something really discreet, given a specific request. I have good success with the "chaining" style of connect middleware, which would look like this:

app.get('/about', function(req, res) {
  res.send('out about page, anyone can see this!');
});

app.get('/dashboard',stormpath.loginRequired,function helloDashboard(req, res) {
  res.send('Hello, ' + req.user.fullName);
});

Thus your implementation of stormpath.loginRequired would look something like:

function loginRequired(req,res,next){
  /*
    do stormpath API stuff to figure out if this user is logged in

    if they are not, you have to decide how to handle that

    you could pass an error to next(), and expect the helloDashboard middleware to deal with it

    you could just redirect them to a login page and  end the request in here, and dont call next()
  */
}

You could support all of those ideas, via options, by having stormpath.loginRequired return a function in response to an options object. That would look like:

function loginRequired(options){
  // setup some closure state to decide how the request will be handled
  return function(req,res,next){
    // do the right thing, based on the options
  }
}

And then you would use it like this:

app.get('/dashboard',stormpath.loginRequired( { doTheThing: true} ),function helloDashboard(req, res) {
  res.send('Hello, ' + req.user.fullName);
});

If the number of options would be really complex, you could also consider implementing several functions such as redirectOnLoginFailure errorOnLoginFailure etc