session
session copied to clipboard
expressjs
Added support for passing session ID using HTTP header
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
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?
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.
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 :)
+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
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: BearerX-* 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.
@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.sessionIDexists (copy & past of your solution) JoeWagner@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 :beers:
+1 for this pull request, I need this feature for my single web page application that uses socket.io + expressjs from another server.
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 ?
@kappuccino You can see how I did it here https://github.com/alexey-detr/session/commit/3c9ef961785b2d86c435af92ec7b4fce2be304fa#diff-306b67b120079e997613897e45b88194R109
@alexey-detr thank you ! if you have already implemented the "session-id via header" why not to make a pull request ?
@kappuccino But I already did so. This thread is a PR or I done something wrong?
my apology. you're right https://github.com/expressjs/session/pulls sound your request has not been pulled yet sorry
@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.
@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.
Travis says "This pull request can be automatically merged by project collaborators."
sounds good guys !
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.
+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.
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..
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.
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.
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.