Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for passing session ID using HTTP header #79

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

alexey-detr
Copy link

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

@@ -28,6 +28,7 @@ Session data is _not_ saved in the cookie itself, just the session ID.
#### Options

- `name` - cookie name (formerly known as `key`). (default: `'connect.sid'`)
- `headerName` - optional HTTP header name to pass session ID, e.g. `X-Session-Token`. (default: `undefined`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

index.js Outdated
}

function getHeader(req, name, secret) {
var header = req.headers[name.toLowerCase()];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Lower casing header name was removed from getHeader() function.
@dougwilson
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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 :)

@dhollenbeck

This comment has been minimized.

@kappuccino

This comment has been minimized.

@joewagner
Copy link
Member

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
Copy link

@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 🍻

@kscc25

This comment has been minimized.

@dougwilson dougwilson self-assigned this Dec 7, 2014
@JSteunou

This comment has been minimized.

@kappuccino

This comment has been minimized.

@alexey-detr

This comment has been minimized.

@kappuccino

This comment has been minimized.

@alexey-detr

This comment has been minimized.

@kappuccino

This comment has been minimized.

@alexey-detr

This comment has been minimized.

@JSteunou

This comment has been minimized.

@alexey-detr

This comment has been minimized.

@Vitaliy-Yarovuy

This comment has been minimized.

@alexey-detr
Copy link
Author

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

This comment has been minimized.

@BonsaiDen

This comment has been minimized.

@stephenliberty
Copy link

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
Copy link
Contributor

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.

@hazemsq

This comment has been minimized.

@simllll

This comment has been minimized.

@lime-green

This comment has been minimized.

@alexprice1

This comment has been minimized.

@jasonbodily

This comment has been minimized.

@dougwilson
Copy link
Contributor

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.

@kappuccino

This comment has been minimized.

@alexey-detr
Copy link
Author

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.

Copy link
Contributor

@dougwilson dougwilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@simllll
Copy link

simllll commented Oct 22, 2016

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

@azachar

This comment has been minimized.

@maximelebastard

This comment has been minimized.

@expressjs expressjs deleted a comment from cojack Nov 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet