hmm sorry yeah that session part is incorrect, not sure how that snuck
in there. It's preferred that session()
gets an explicit secret but either way is fine. We're going to keep
slowly moving those cookie utilities out
into npm so it becomes easier to work with them from other origins
On Oct 24, 1:09 pm, thibaud <thibaud.cummi...@gmail.com> wrote:
> on the migrating from 2.x to 3.x<https://github.com/visionmedia/express/wiki/Migrating-from-2.x-to-3.x
> it says:
> Use express.cookieParser('secret') instead of passing the secret to the
> express.session() middleware. The 'secret' option in theexpress.session() middleware
> has been removed.
> but pretty much every where else I don't see any confirmation of this.
> it seems it is rarely encouraged actually as examples for connect's session
> middleware always uses a secret in the session middleware but seldom in the
> cookieParser one...
> first off, I'd like to know the difference in between setting a secret in
> the cookieParser middleware or in the session middleware and which
> is preferred ?
> I would like to create a module for the usual problem of
> express/socket.io's session sharing business for the option suggested here<https://github.com/senchalabs/connect/issues/588#issuecomment-8203119> seems
> slightly odd.
> I feel it is a bit of a hack because a cookieParser first argument is
> intended to be a 'res' stream and it happens that socket.io's handshakeData
> has the same structure than the res stream; they both have a headers object
> which contain the cookies' objects.
> @tj do you also think of this as a slightly 'hacked' way of doing this?
> now that you have extracted the cookie signature<https://github.com/visionmedia/node-cookie-signature> feature
> out of connect, I thought it would be better to build a module that uses
> that... that's why I wanted to know precisely about the possible cookie
> objects created.
> there seems to be two possible cookie 'objects' set for cookies. either
> 'signedCookies' which happens when the secret is provided in the
> cookieParser or simply 'cookies' which is set if the session's middle get a
> this<https://github.com/functioncallback/session.socket.io#cookie-lookup-p...> project
> seems to also cater for a 'secureCookies' object but I don't see that
> anywhere in connect/express source; it seems the distinction in only
> internal to connect/express and if one uses an https connection
> the cookies are still exposed via one of the two 'cookie' or
> 'signedCookies' as mentioned above.
> hope you can clear that one out for me and thanks again for all the quality