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.
Related
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.
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 am currently working on a chatbot for Facebook Messenger. I am working with the Microsoft bot framework and the code is written in node.js.
I am interacting with a database through an api. With every request I have to pass an access token inside the request header. I have read on the internet that you would usually store such a token inside a cookie or web storage. However I also found out that you can't do that on Facebook Messenger. I was thinking about storing the access token inside a variable, but my concern is that this might not be secure. Is there any other secure way to store the access token?
I am fairly new to node.js and it is my first time working with tokens. Help is much appreciated.
You can use session.userData to hold your database token. If you are concerned about it being secure, then encrypted it before saving.
session.userData.dbtoken = encryptToken(token);
The token can later be retrieved and used when you need it:
var token = decryptToken(session.userData.dbtoken);
var databaseData = getUserDataFromDatabase(token);
https://docs.botframework.com/en-us/core-concepts/userdata/
Or, use a local database like NeDB: https://github.com/louischatriot/nedb This would be the most secure option, since the database would reside on your server.
I would suggest using express-session. for the following reasons.
Create a session middleware with the given options.
Note Session data is not saved in the cookie itself, just the session ID. Session data is stored server-side.
Note Since version 1.5.0, the cookie-parser middleware no longer needs to be used for this module to work. This module now directly reads and writes cookies on req/res. Using cookie-parser may result in issues if the secret is not the same between this module and cookie-parser.
Warning The default server-side session storage, MemoryStore, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.
Assuming this token does not change, you can store it as an environment variable, say TOKEN and access it in nodejs app as process.env.TOKEN.
Super simple question that I'm having trouble wrapping my head around.
When using sessions with nodejs, are the sessions stored in the users browser? Or are the sessions stored on the server?
For example, if I'm using the express-session or passport.session(), where are these session cookies stored?
As #robertklep mentioned, sessions (in the way you're using them) are stored on the client, but only contain a session ID. When your request hits the web server, it'll then look up the session ID to grab the account from some sort of database / cache, then use it for the remainder of the request lifecycle.
If you're interested on learning more about this, you might want to check out this screencast I made a while ago which covers exactly how cookies work, and why -- as well as how to store them securely: https://www.youtube.com/watch?v=yvviEA1pOXw
Furthermore, if you're looking to build a site that doesn't use 'typical' server-side sessions, and works with modern client-side front-end web frameworks like Angular.js / React.js / etc., you might want to investigate JSON Web Tokens (JWTs). These tokens allow you to create 'dumb' cookies that don't require a database lookup on the server, and can speed up your web apps / API services pretty dramatically: https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/
Hope this helps!
The fine manual states:
Note Session data is not saved in the cookie itself, just the session ID. Session data is stored server-side.
express-session sends a cookie to the browser (which stores it), which contains a unique session id. The data itself is stored on the server (depending on which session store you use, this can be in memory, Redis, MongoDB, ...).
The session id in the cookie is merely used as a key to look up the actual data in the session store.
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 =)