Sessions In API's

[wesleytodd]

Note: So I am sorry if this is a duplicate of something else, but most of the issues I found relating to this are not all that helpful.

Using the RedisStore, but this is not redis specific, I was planning on sharing my sessions between a bunch of API microservices and a web app. Obviously I don't want to use cookies for these api's, I want to use the auth header. But the same session will also be accessed from my web app, which will use cookies.

To solve this I would like to generate a single token to act as both my cookie value and my auth header. When my web app makes a request to an api it would just load the cookie value into the auth header.

At my work we have a session module that does this and it works great, but it is not open source. I was hoping to get your opinion on having this module support that. Do you like the idea? Do you know of another module that already does this? Is there a way to get this module to do that already that I am just stupidly missing? I would be happy to get this working in a PR or make a proof of concept first, just let me know.

[wesleytodd]

So, I looked into the code a bit, and it looks like we could pretty easily break the main body of this code out into two drivers, which would just be middleware generator functions:

• Cookie: Gets and sets session in a cookie, basically the code that is here
• Header: Gets from the header but provides a method for generating the token to return to the client on authentication

This is basically the architecture we use at work for our session module.

[wesleytodd]

https://github.com/wesleytodd/session/tree/api-sessions

I was pretty easily able to get the test passing after moving most of the login out into a driver. I'm going to try and get a header implementation working next.

Even if this doesn't look like something you guys would want to merge, I might maintain a fork, as I have needed something like this a few times in the past.

[dougwilson]

Yes, this is desired. I'm currently out for the holiday weekend where I am, but I wanted to give you that feedback and let you know you're not being ignored :)

[wesleytodd]

Awesome! I just got it working in my api, it is very rudimentary, and to really get something good the entire module will need some attention. But on that branch I linked to above you can see my 2 commits.

The things that would need to change to make this implementation clean:

• The req.session.cookie value is a misnomer in that the header driver just uses it for the maxAge stuff. Would be better to call it something like res.session.config.
• The current header driver doesn't do any signing. My thought here is that it is not common practice to sign bearer tokens, they are just sent as is. Which makes the secret NOT required. This would probably need discussion.
• The drivers would be better broken out into separate small modules. But right now they are way too specific. They could easily be made into more generic modules that other people could use as the basis for different session implementations.

Anyway, not all of that would be required, I mean i have it working right now on that branch. But it would be better than it is now if we did it.

[wesleytodd]

Any feedback on my progress there would be awesome. I will hopefully be able to do a bit more work on this soon, and would like to know first if you all like my direction. I can take a different direction if you have any better ideas!

[dougwilson]

It sounds good :) There is a PR going on, it seems (#164) that seems kinda similar (?). How does your stuff compare to that PR? Why not just make a PR and we can discuss over code :)? The main desirable property right now is to be backwards-compatible, at least until August.

[wesleytodd]

Ill have a look at that tonight and let you know! I believe mine maintains backward compat fwiw.

[wesleytodd]

Is there any interest in this PR?

Let me expound on the situation here:

In a SOA environment, most html delivering "web clients" (aka front-ends), will only use the cookie as a pass through to the api layers. So I actually removed this middleware entirely from my client apps and ONLY pass the cookie value through as Authorization: bearer <COOKIE_VALUE> via the code in this PR.

The way you previously had to do this, with this middleware, was by parsing the cookies in your web client, then setting your sid cookie onto the api requests you were making behind the scenes. Then the api would also have to parse the cookies to get it out. The issue here is that for most situations, api's also have to support authorization headers because of things like native clients and other common best practices. Which complicates the api's a fair bit.

This PR should be fully backward compatible because the default driver is still the cookie, but driver option allows for users to set the header option to parse the session id value from the authorization header.

Since this PR is almost a year old, I realize that it needs some clean up, like adding documentation and removing the version bump that I added for some unknown reason :) But if you all like the looks of it I can do that clean up so we could maybe get this merged?

[wesleytodd]

I realized I didnt re-link to the PR, so here is the link to the actual code: #170

[daaru00]

Is there a internal method to load session from its id?
so, we can create a middleware that load the session based on a custom header (valorized with session id used as a session token).

[wesleytodd]

Are you meaning like this? https://github.com/expressjs/session/blob/master/index.js#L405

#170 is doing what you are asking, "loading the session based on a custom header". This PR allows for passing the session id as an Authorization header or some other custom header you specify. Does that help?

If you are interested in this feature, please make some noise so we can make some traction on it.

[daaru00]

Are you meaning like this? https://github.com/expressjs/session/blob/master/index.js#L405

nearly, I mean something like this:

var session = require("express-session");
app.use(function(req, res, next) {
    var session_id = req.header("x-session-token");
    req.session = session.getById(session_id); //like this
    next(); //here session is loaded
});

This would lead to implement a session sharing across multiple devices:

var session = require("express-session");
app.use(function(req, res, next) {
    var token = req.header("x-session-token");
    var user_id = getUserIdFromToken(token); //my internal method
    var session_id = getUniqueSessionIdBasedOnUser(user_id); //my internal method
    req.session = session.getById(session_id);
    next(); //here session is loaded
});

this is only an idea but with a method like this I can implement it.

If you are interested in this feature, please make some noise so we can make some traction on it.

yes, I'm very interested, my problem would be resolved!

[wesleytodd]

If #170 lands, you should be able to let this module do all that work for you, for example:

app.use(session({
  driver: 'Header',
  name: 'x-session-token'
}));

app.get('/', function (req, res) {
  if (req.session && req.session.userId) {
    console.log('user logged in');
  } else {
    console.log('no logged in user');
  }
});

And it will do exactly what you are doing where you could just access req.session. The Header driver defaults to loading from a standard bearer token format of Authorization: bearer <session_id>. But by overriding the name you can use whatever header you want.

[daaru00]

Exactly, I'll wait for this feature. 👍