I'm learning Node.js, and I was wondering what is the best way to handle sessions.
It occurs to me that there are two main options: express-session, or cookie-session.
I did some research, and I've found that express-session is not the best way, since it stores all session information on the server, making it less scalable, but lots of tutorials were recommending it.
So, I am a little confused.
These two options are not comparable as they don't have the same functionality.
If you just want to set up a "volatile" session, with no need to store/verify any information server side, you can use cookie based session. This is just an improvement for the user experience (remember choices, preferences...)
On the other hand, if you need to keep some record about that user (authentication, history...), you will need to use a server side session, and a database. Any client side data (like cookie) could be modified by the user.
Note that the last option is not less scalable, it depends on the storage method, MemoryStore by default in express-session package, according to the documentation.
This package is powered by express team, so I guess it is robust enough for a production usage.
Related
we are in the process of building a new app in node.js with express that connects to our parse server backend. We have built native apps that already connect to our backend on iOS, Android and PHP. All of them have the ability to log in the user and store the session data securely.
I'ts my understanding that node.js doesn't really store sessions like for example in PHP you can store them as a file on the server or to memcache or redis and test against parse->currentUser() to check if its valid.
How does one do this with node.js? We cant store any session data in a cookie since thats not secure.
Is using express-sessions and redis a good way to handle this?
I'ts my understanding that node.js doesn't really store sessions like for example in PHP...
That's not a totally accurate understanding... it's more that Node.js doesn't really know or care how you handle your sessions. That's where frameworks like Express, and their modules express-session, come into play.
Is using express-sessions and redis a good way to handle this?
If you're using Express, yes. And, with that, you can use whatever session store you want, including Redis, Memcached, files, just like you're used to with PHP.
An approach that I've used in the past is to store your session ID in a cookie, but none of the session content. That will allow you to reconnect with a prior session, as long as it's still valid. You can also use LocalStorage if you want something a little more persistent than SessionStorage. If you want something really persistent, you can manually save your session data to your database, and have the user request it if their browser data has been cleared.
I just read an article about ExpressjS security best practice here https://expressjs.com/en/advanced/best-practice-security.html . And it mentions that express-session package is only designed for development environment, not production environment. So wheter it means that i can't use express-session for implementing authentication and authorization functionality in my apps? How if i use it in production environment? Is there security issues or what? Please help to explain. Thank you.
You misinterpreted what was written about it.
The express-session middleware stores session data on the server; it
only saves the session ID in the cookie itself, not session data. By
default, it uses in-memory storage and is not designed for a
production environment. In production, you’ll need to set up a
scalable session-store; see the list of compatible session stores
It meant that you should use external store to use session (like a DB or a key-value store like Redis) to prevent session data loss in case your app restarts or crashes.
I'm investigating using Stormpath for our user Management.
I currently have a Sails.js application which uses Node.js / Express.js. Currently, session management is handled by the default Sails.js framework, which relies heavily on Express' session middleware.
Sessions are stored in a shared Redis database on production so that we can keep our multiple API servers stateless.
My question is will the two session management systems conflict and/or cause bugs? Do they have to be consolidated or can we safely keep them separate? if they have to be combined, how do you configure the middleware?
As a note we won't be storing much user data on Stormpath, we'll only be using them as a auth/token provider.
Thanks for the help!
I'm the author of the express-stormpath library, which is what I'm assuming you're evaluating.
You can indeed use your own sessions in addition to the stormpath ones. The way it works is like so:
Stormpath uses req.session to store a stormpathSession cookie. Any other cookies you create / store, will be handled by you completely.
It should work nicely with whatever session library you choose =)
I am building an app using expressjs, I want to use sessions where session data is stored in server-side and the cookie only contains the encrypted key to it. I seen a lot of examples that express does the same. But my problem is that they seem to use express.session where as Express docs doesn't specify any such middleware right now. It has cookieSession and I am not very sure as to what kind of sessions it provides.
I tried to search for the same, but could not find any suitable information, so this question. Please help me out.
If it only cookie-based encryption and holds all the data in the cookie only. Than I just wanted to know is it safe enough to be used. I know it can't be tempered and all. But still I get a feeling that the best option is the one I mentioned above.
If it the same as express session than I have one more question as to which session data-store should I use? I want it to be fast and also reliable(it doesn't get deleted). Basically my choice is between connect-redis and connect-mongo.
Please help me out.
I have found the answer why its not available in express docs because it comes from connect and its the same as connect.
Regarding the better option, I think its better option to store the data in server-side, though some might argue that its better to store client side for scalability...but you cant compromise security for scalability.
I wrote a simple webserver with nodejs and express. I implemented an user authentication with email username and password. Furthermore I have a remember-function which stores the user id and pwd hash into a cookie. Now I would like an extra session that ends when the user will close his browser or click to the logout button.
Which way is the best practice for implementation? Is the session the same like the remember-function with an expire time and in each request I must check the credentials against the database? (I'm not that sure about this)
Technologies that I'm using: nodejs, express, mongodb
This is not a nodejs question only, I would prefer a general explanation for the problem.
Let me get this out of the way first; Storing the password hash into a cookie would allow anyone to login when they have the password hash and that would be disastrous if the password hashes ever got exposed for some reason. Encrypting cookies is just fine, but don't allow the actual hash you store in the database to be used for authentication. Ever.
About re-authentication, Node is a technology that operates on a single thread and is scaled by running more instances over multiple processors and/or machines. Keeping sessions is a good idea to avoid trips to the database, but you have to think about the architecture as well. What happens if you, say, use sessions stored in files (ala PHP) and you need to scale to multiple machines? Nothing good, at least. So you need a central point to keep track of the sessions.
This can be either your database (MongoDB) or something such as Redis, or another centralized mechanism allowing you to check sessions. Either way, you will have to spend time doing the request and retrieving the session values for the client. If you do not have additional values you need to store it makes no sense to create a dedicated session architecture (that needs expiration, and so forth) and just doing the authentication again is the easiest and most logical solution.
Personally I almost never need sessions and just do authentication again.