> 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
> secret...
> 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
> projects.

> regards,

> thibaud.