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
from

Conversation

Projects
None yet
@alexey-detr

alexey-detr commented Aug 19, 2014

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

This comment has been minimized.

@Fishrock123

Fishrock123 Aug 19, 2014

Member

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

This comment has been minimized.

@alexey-detr

alexey-detr Aug 19, 2014

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

This comment has been minimized.

@billwen

billwen Mar 2, 2017

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

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

@Fishrock123 Fishrock123 added pr labels Aug 19, 2014

index.js Outdated
}
function getHeader(req, name, secret) {
var header = req.headers[name.toLowerCase()];

This comment has been minimized.

@Fishrock123

Fishrock123 Aug 19, 2014

Member

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

This comment has been minimized.

@alexey-detr

alexey-detr Aug 19, 2014

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

This comment has been minimized.

@dougwilson

dougwilson Aug 19, 2014

Member

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

This comment has been minimized.

@alexey-detr

alexey-detr Aug 19, 2014

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

This comment has been minimized.

@dougwilson

dougwilson Aug 19, 2014

Member

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

Option 'headerName' was renamed to 'header'.
Lower casing header name was removed from getHeader() function.

@dougwilson dougwilson force-pushed the expressjs:master branch 3 times, most recently from 9ff5ab5 to 5936c25 Sep 7, 2014

alexey-detr added some commits Sep 23, 2014

@dougwilson

This comment has been minimized.

Member

dougwilson commented Oct 17, 2014

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

This comment has been minimized.

alexey-detr commented Oct 17, 2014

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

This comment has been minimized.

Member

dougwilson commented Oct 17, 2014

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

@dougwilson dougwilson force-pushed the expressjs:master branch from 6433157 to 6a0cd2d Oct 22, 2014

@dhollenbeck

This comment was marked as off-topic.

dhollenbeck commented Oct 27, 2014

+1 for this pull request.

@kappuccino

This comment was marked as off-topic.

kappuccino commented Nov 13, 2014

+1
Could be usefull when a page in called from a script (not from a browser). In this case (php client of a restfull api for example) it is easier to send a header instead of setup a cookie

@joewagner

This comment has been minimized.

Member

joewagner commented Nov 13, 2014

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

This comment has been minimized.

kappuccino commented Nov 15, 2014

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

@heroandtn3

This comment was marked as off-topic.

heroandtn3 commented Dec 6, 2014

+1 for this pull request, I need this feature for my single web page application that uses socket.io + expressjs from another server.

@dougwilson dougwilson self-assigned this Dec 7, 2014

@JSteunou

This comment was marked as off-topic.

JSteunou commented Dec 16, 2014

+1

@kappuccino

This comment was marked as outdated.

kappuccino commented Dec 17, 2014

I am ready to make the pull request but my unit test is not ready.
I make a first request with no header and i catch the session-id in response headers.
then I make another request with session-id in my "request headers"... but i do not figure how to do it.

it('should modify cookie when changed to large value', function(done){
request(app)
.get('/')
....

any idea ?

@alexey-detr

This comment was marked as outdated.

alexey-detr commented Dec 17, 2014

@kappuccino

This comment was marked as outdated.

kappuccino commented Dec 17, 2014

@alexey-detr thank you !
if you have already implemented the "session-id via header" why not to make a pull request ?

@alexey-detr

This comment was marked as outdated.

alexey-detr commented Dec 17, 2014

@kappuccino But I already did so. This thread is a PR or I done something wrong?

@kappuccino

This comment was marked as outdated.

kappuccino commented Dec 17, 2014

my apology.
you're right https://github.com/expressjs/session/pulls
sound your request has not been pulled yet
sorry

@alexey-detr

This comment was marked as outdated.

alexey-detr commented Dec 17, 2014

@kappuccino that's ok, I'm a newbie in making pull requests, so probably I could made something wrong. I'm also waiting for request to be pulled in or this feature will be implemented in another way.

@JSteunou

This comment was marked as outdated.

JSteunou commented Dec 17, 2014

@alexey-detr you should update your PR because it cannot be merged at the moment.

This pull request contains merge conflicts that must be resolved.

@alexey-detr

This comment was marked as resolved.

alexey-detr commented Dec 17, 2014

@JSteunou thank you for advice! PR should be updated now.

@kappuccino

This comment was marked as outdated.

kappuccino commented Dec 17, 2014

Travis says "This pull request can be automatically merged by project collaborators."

sounds good guys !

index.js Outdated
@@ -178,6 +189,9 @@ function session(options){
}
setcookie(res, name, req.sessionID, secret, cookie.data);
if (headerName) {
setHeader(res, headerName, req.sessionID, secret);
}

This comment has been minimized.

@JSteunou

JSteunou Dec 17, 2014

So setting a headerName will set the session id in header and cookie. Should this be exclusive?

This comment has been minimized.

@alexey-detr

alexey-detr Dec 17, 2014

This made to provide backward compatibility when part of front-end code still using cookie based authorization.

This comment has been minimized.

@JSteunou

JSteunou Dec 17, 2014

Should the user put this in settings explicitly for having both? If I will use this functionality to have session id in headers, I will not want it in cookie no more.

This comment has been minimized.

@alexey-detr

alexey-detr Dec 18, 2014

Good point. You are right, user should have an ability to choose what type of session id passing he wants to use. I will try to update PR to support your suggestion.

@dougwilson dougwilson force-pushed the expressjs:master branch from 869b2f3 to b5e6332 Jan 5, 2015

@Vitaliy-Yarovuy

This comment was marked as off-topic.

Vitaliy-Yarovuy commented Jan 8, 2015

+1

@alexey-detr

This comment has been minimized.

alexey-detr commented Jan 11, 2015

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 was marked as outdated.

stephenliberty commented Feb 24, 2015

So.. when's this getting pulled in?

@BonsaiDen

This comment was marked as off-topic.

BonsaiDen commented Feb 24, 2015

+1 Would be great to have this in shortly, don't want to re-implement it on my own when it's pretty much already being presented here on a silver platter.

@stephenliberty

This comment has been minimized.

stephenliberty commented Feb 24, 2015

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 dougwilson force-pushed the expressjs:master branch from 667780a to 7c6da9c Mar 30, 2015

@dougwilson

This comment has been minimized.

Member

dougwilson commented Apr 25, 2015

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 dougwilson force-pushed the expressjs:master branch from 216343a to df021bb May 5, 2015

@hazemsq

This comment was marked as off-topic.

hazemsq commented Oct 7, 2015

+1 to have this in shortly

@simllll

This comment was marked as off-topic.

simllll commented Jan 23, 2016

any news on that?

@lime-green

This comment was marked as off-topic.

lime-green commented Feb 11, 2016

+1

@alexprice1

This comment was marked as off-topic.

alexprice1 commented Jun 7, 2016

bump

@jasonbodily

This comment was marked as off-topic.

jasonbodily commented Sep 14, 2016

Very much interested in this. It's been mentioned this is a 'rare' case. I'm familiar with no other way to authenticate and persist sessions against an API cross domain, as cookies can't be shared. Please merge or address this situation.

@dougwilson

This comment has been minimized.

Member

dougwilson commented Sep 14, 2016

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 was marked as off-topic.

kappuccino commented Sep 14, 2016

@dougwilson, what are you suggesting ? we should create a middleware just to manipulate this Header ?

@alexey-detr

This comment has been minimized.

alexey-detr commented Sep 15, 2016

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

This comment has been minimized.

simllll commented Oct 22, 2016

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

@azachar

This comment was marked as off-topic.

azachar commented May 16, 2017

So what is the progress on this? Thx.

@maximelebastard

This comment was marked as off-topic.

maximelebastard commented Nov 8, 2018

Hi, some news about this one ?

Despite of agreeing on adding a manual way to set the Session ID, #159 has been closed 6 months ago. Multiple PRs seems to try to resolve the same issue (using something else than a cookie to store the Session ID) - but all of them have been closed or are waiting for a merge since a long time.

The usage of cookies to store the session id can be painful because of recent the GDPR law or the anti-tracking extensions. Moreover, Safari 11 (~15% of global trafic, 600 millions users) blocks a lot of cookies by default. And it will become a worse time for cookies in the coming years.

Express is the most popular web javascript framework, and javascript is one of the most popular web languages. It's a shame that this middleware does not handle this case...

@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