Added support for passing session ID using HTTP header

[alexey-detr]

These changes add new option headerName that can be used to optional passing session ID using custom HTTP header.

Already discussed this issue in #77

[Fishrock123]

Discuss: change to just header, or probably better, id-header?

[alexey-detr]

@Fishrock123 I think header will be better name for this option.

[billwen]

in index.js
var signed = 's:' + signature.sign(val, secret);

secret is an Array, instead of a string, so your code has broken.

[Fishrock123]

Hmm I don't think it should be lower-casing it.

[alexey-detr]

@Fishrock123 Express.js lower-casing all header names in req.headers object, so it must be lower-cased. Package user can write header name in any case. Probably I should add a test for case-insensitivity of header name option?

[dougwilson]

since this is an internal help function, it can make assumptions. just lc the header on the constructor so it's done only once

[alexey-detr]

@dougwilson but if I convert header name to lower case in the constructor, package user will see lower-cased HTTP header in response, is this ok? I beleive package user should see exactly what he passed to the options.

Probably there should be two variables, one for getHeader function and one for passing unchanged header name back in the response?

[dougwilson]

right. i haven't yet read through the changes :) but yes, we should only lc one time. if we need both representations, then just store both

[dougwilson]

Hi @alexey-detr I'm so sorry I have not paid attention to this PR :( So I was looking over it, and to me, it seems a little weird for someone to be wanting to read from a header the signed session ID value, and especially to want to write out a response header with this value. an you explain to me a little bit about your use-case that inspired you to implement this?

[alexey-detr]

Hi! If you remember we already discussed it in #77. Actually it is a very rare use case when requests are sending with AJAX + CORS. I'm still not sure if such implementation should be in this package, because it doesn't look solid. But this feature is necessary for my project so I created fork with private branch for my needs.

[dougwilson]

If you remember we already discussed it in #77.

Sorry, I forgot :) There are just so many things to remember, and it's mainly just hard to remember people's GitHub handles and put together with convos, sorry!!

Ok. So I understand what you are saying. Basically, to me, it sounds like you want to be able to have something you can use as a Bearer token (think OAuth) and have that token load up a session using this module. I'll look into making this possible, even if you may have to add a little bit of code in your app to do it, but then you won't have to maintain a fork for no reason :)

[joewagner]

What if we look to see if req.sessionId has been set by an earlier piece of middleware, and use that if it exists?
We could basically just do this
That would allow the use of a Authorization: Bearer as well as an X-* type header. For @alexey-detr use case the getHeader and setHeader functions would live in middleware before this module, and they would set req.sessionId appropriately.

This would require a good explanation in the docs, but I think it would be more extensible.

[kappuccino]

@joewagner I try your solution it is working and consists in :

• A middleware before express-session to catch a specific header (x-session-id) and inject it in req.sessionID
• A patch of express-session to check if req.sessionID exists (copy & past of your solution) joewagner/session@fc55f78
• A third middleware to set x-session-id header in the response headers

This last middleware allow the client to grab the session ID easily (no need to parse the set-cookie header — still here but not uses in my case)

In my opinion, a better solution could be to merge all this in expressjs-session middleware and add an extra parameter in configuration object (the header name)

if someone is interested, i can propose my solution wrapped in a pull request 🍻

[alexey-detr]

Guys I have updated the PR. Now it is possible to specify cookie option as null, so cookies will not be ever sent with responses. Tried to implement it when cookie option is not specified at all, but it breaks backward compatibility. Setting cookie as null allows to use only headers to pass session id.

[stephenliberty]

FWIW, the express-mysql-session package (and maybe others) specifically look for cookies.. so this doesn't work for them. Issues should be opened on those packages once this finally makes it in..

[dougwilson]

FYI for those coming by here waiting for this to be implemented, for now the only work-around is to add the session ID in the req.signedCookies object provided by cookie-parser module.

[dougwilson]

Please merge or address this situation.

Just looking through the PR, there was a comment on the name of the option, which was only partially changed; the docs (where the comment still remains) hasn't been updated. Also, the PR currently has conflicts and can't be merged just as a general comment.

Even then, there are multiple threads discussing this topic, at in at least one of them, it was said I would rather accept an PR that allowed a user to read the session ID out in whatever way they choose, instead of still locking them into the decisions of this library. For example, you are locked into Cookies because that's who this module did; this PR would now just lock you into Cookie or a Header, which is not a generally better situation, just a quick Band-Aid that should be better addressed in some PR, please.

[alexey-detr]

this PR would now just lock you into Cookie or a Header, which is not a generally better situation, just a quick Band-Aid that should be better addressed in some PR, please.

Totally agree with @dougwilson. There should be a better more general solution for this problem. For example it could be an optional callback functions specified in configuration that will fetch/save session ID in any way you want. So you will be able to pass session ID in cookies, headers, query string, custom field of JSON-objects in POST request... Not just only cookie or header.

[dougwilson]

PR needs to be reworked following the discussion in the comments. Also resolve merge conflicts.

[simllll]

Just for reference: the above mentioned more general solution can be found in PR #159

[witherBattler]

Can someone please check this PR out? It's very needed now since third party cookies are blocked in most browsers...