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 =)
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 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.
Feathers auth provides only JWT authentication, even if strategy is local.
Should I make full custom middleware for express-session usage and clean passport implimentation just to achive regular sessions behaviour or there's some solutions for this purpose?
Also, I want to use passport.socketio for autheticate sockets aswell.
Using Feathers authentication module is entirely optional and you can always register your own middleware at any point like before and after a service. This means you can set up a normal Express session setup and then set req.feathers to the information from the session that you also want to pass to Feathers services (like the user). As you mentioned, you will have to do the same thing with websockets (which also allow setting handshake.feathers in its middleware).
A full tutorial how to set up sessions and using authentication can be found in the Using A View engine cookbook documentation.
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.