Sessions: req.session or res.cookie?

[NHQ]

Are these the same? Does setting a req.session.variable leave a cookie
with the data, or just an ID?

is it okay for me to use an email, a la mode req.session.user =
user.id, because email is the key I use to store user credentials in
redis.

[Laurie Harper]

On 2011-02-26, at 8:45 PM, NHQ wrote:
> Are these the same? Does setting a req.session.variable leave a cookie
> with the data, or just an ID?

They're not the same, no. res.cookie adds a cookie to the response; req.session is a server-side key/value store. Session data lives in server memory by default, although you can configure alternate stores.

> is it okay for me to use an email, a la mode req.session.user =
> user.id, because email is the key I use to store user credentials in
> redis.

You can store anything you want in a session. The only thing the client sees is a cookie identifying the session.
--
Laurie Harper
http://laurie.holoweb.net/

[NHQ]

So but req.session uses a cookie? Just not the same cookie as if I
were to create one for res.cookie? DO I have to make my own database
tokens for cookies I make, or does session take care of that as well?

I use connect-redis for sessions.

[Laurie Harper]

The session middleware sets a single cookie to identify the session. Besides that one session identifier, there are no cookies involved. Using res.session has no effect what-so-ever on what cookies the client sees. Sessions and cookies are entirely separate systems.

You can store anything you want in the session, and no extra cookies will be created. On the other hand, if you create a cookie (by calling res.cookie()), the session isn't touched; the one has nothing to do with the other.

Cookies are created by calling res.cookie(), and are sent to the client as part of the response, stored by the client, and sent back to the server with each subsequent request. Sessions are stored by the server, and never sent to the client.

I have no idea where database tokens might come into it... you don't need any kind of database to use cookies, or to use sessions. You can remove all references to connect-redis from your project and your use of sessions/cookies wouldn't change one bit.

The connect-redis module is just a session store: it saves session data (anything you put in req.session) to your redis database. It doesn't know anything about cookies. It doesn't send anything to the client. If you stopped using it, the *only* thing that would change is that your session data would be held in memory on the server, rather than saved into your redis db.

Does that answer your question?

L.

> --
> You received this message because you are subscribed to the Google Groups "Express" group.
> To post to this group, send email to expre...@googlegroups.com.
> To unsubscribe from this group, send email to express-js+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/express-js?hl=en.

[vision media [ Tj Holowaychuk ]]

Thanks for the nice responses Laurie! appreciate the help 

Tj Holowaychuk
Vision Media
President & Creative Lead

[Laurie Harper]

No problem -- explaining how things work is a good way to increase my own understanding ;-)

[vision media [ Tj Holowaychuk ]]

very true :)

[NHQ]

Yes thanks. I get it!

On Feb 27, 2:27 pm, "vision media [ Tj Holowaychuk ]" <t...@vision-

[daslicht]

Hello,

I have created a simple app to try out sessions which works nice.

If I set something like this: 

req.session.currentUser

I can access it in other routes like this: 

currentUser= req.session.currentUser

But as far as I add the secure option to true its no longer working.

Here is the config:

app.use(express.cookieParser('secret'));

app.use(express.session({ secret: 'secret', key: 'sid', cookie: {secure: true, maxAge: 60000 }}));

 What Am I missing ?

[Hage Yaapa]

Secure cookies will be sent via HTTPS only. Have you set up an HTTPS server? Also, which version of Express are you using?

--

You received this message because you are subscribed to the Google Groups "Express" group.

To unsubscribe from this group and stop receiving emails from it, send an email to express-js+...@googlegroups.com.

To post to this group, send email to expre...@googlegroups.com.

Visit this group at http://groups.google.com/group/express-js.
For more options, visit https://groups.google.com/groups/opt_out.

[daslicht]

On 16.08.2013, at 19:27, Hage Yaapa <cap...@hacksparrow.com> wrote:

Secure cookies will be sent via HTTPS only. Have you set up an HTTPS server? Also, which version of Express are you using?

NO I haven't ! 

very nice, thank you very much ! now I feel better :)

btw here is my playground : https://github.com/daslicht/expressjs-jade-session-playground

:)

On Fri, Aug 16, 2013 at 10:12 PM, daslicht <ans...@gmail.com> wrote:

Hello,

I have created a simple app to try out sessions which works nice.

If I set something like this: 

req.session.currentUser

I can access it in other routes like this: 

currentUser= req.session.currentUser

But as far as I add the secure option to true its no longer working.

Here is the config:

app.use(express.cookieParser('secret'));

app.use(express.session({ secret: 'secret', key: 'sid', cookie: {secure: true, maxAge: 60000 }}));

 What Am I missing ?

--
You received this message because you are subscribed to the Google Groups "Express" group.
To unsubscribe from this group and stop receiving emails from it, send an email to express-js+...@googlegroups.com.
To post to this group, send email to expre...@googlegroups.com.
Visit this group at http://groups.google.com/group/express-js.
For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to a topic in the Google Groups "Express" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/express-js/de9sf9Ly_rY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to express-js+...@googlegroups.com.

[Hage Yaapa]

Great! By the way, I wrote a book on Express which covers cookies and sessions in great detail; Google has an good preview of it, check it out - http://books.google.co.in/books?id=nQ_I1yuV_DwC&printsec=frontcover#v=onepage&q&f=false.

[daslicht]

awesome ! 

thanks !

I will have a look into it.

[deitch]

This is a great detailed explanation by Laurie! 

It may be too early in your app, but it is worth thinking about the impact of express sessions vs cookies.

As Laurie explained, no matter how much you stuff into your express session (i.e. server-side session), all the client will see is one cookie identifying the session. This is pretty much a "good thing." 

The downside is that your session is now tied to this particular nodejs server. If it goes belly up, or you scale horizontally so you have 5 servers all serving up information, your user will have to be tied to that one server, which hurts your scalability.

There are two answers to this:

• Store your sessions in a common data store (I have seen that pattern quite often with Mongo).
• Use cookies only. This is the ultimate scalability solution - as long as the customer is around, the session info moves with him - but it only works if you have a limited amount of data to store; sending 1MB through cookies will not work well! - but is great for small scale. You also need to think about security considerations: if it is all in a cookie, what would be so hard about spoofing the cookie, unless you make it cryptographically secure, i.e. digitally sign it and validate. But that may not matter to you.

I used some combination of both for cansecurity authentication, sessions as an option, but also their own built-in sessions that identify a user as authenticated using simple digital signing, so an authentication (but not all of the session data) can carry across servers. 

In any case, I try to make my apps completely stateless on the server side, keeping data about persistent state on the database only, and temporary state (i.e. location inside the app, forms filled in, etc.) client-side only via an SPA. But that design pattern has to work for you.

[daslicht]

What Do you think of using the Browsers LocalStorrage to manage sessions ?

You received this message because you are subscribed to a topic in the Google Groups "Express" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/express-js/de9sf9Ly_rY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to express-js+...@googlegroups.com.

To post to this group, send email to expre...@googlegroups.com.

[deitch]

I like it, when available. It is the same as the pattern I usually use - stateless REST on the server (except for authentication, so you don't have to login every time), auth session handled by digitally signed cookie (see the source code for https://github.com/deitch/cansecurity for how I like it), and all other temporary session state in the browser memory.

LocalStorage buys the ability to store it across window or instantiation instances. The pattern above means if I close my window and come back, my temporary state is lost. LocalStorage means I can pick it up later.

[Eddy]

Mark. thanks Laurie !

在 2011年2月27日星期日UTC+8上午9时45分52秒，NHQ写道：