How can I create sessions and manage them in Node.js without a framework like express?
I know it would be much easier to use express but I want to know how to do it with node just in case.
Most of the questions that mentions managing sessions in node is using express to do so but I want to know how to do that without express.
As a simple starting point, suppose we starts sessions when a user login and destroy when he logout.
So when a user login, we basically create a unique session-id and store this session-id at some db like redis/mysql at our server, same will be given to client for next subsequent requests. (Note do not store session-id in memory of the server, as if the server restart we will loss this sessions)
So next time whenever a new request come from the client with session-id we will identify the user and serve response on the basis of that session-id.
Whenever user logout, we remove the session-id from our db. Similarly we can add timeout for the session-id.
This is a simple concept, it can be extended as required.
Related
I want to make a simple app using MERN (Mongo, Express, React, Node), in which only one person will have to upload pics or write a blog; clients can only view in general. So, I want to create one user authentication. How can I achieve this?
Store sessions in the database
Add a field called, say, "inuse" to the session document
Set that field to 1 when storing the session
Add a unique index with that key
This will prevent your application from being able to store more than one session at a time.
You would then need to devise a mechanism for expiring sessions that are abandoned (i.e. user doesn't explicitly click "log out" button) as well as figure out what to do if, say, your browser crashes and you can't use the established session but it's still within the session inactivity timeout.
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 trying to setup a user login system with Node.js (Express), Socket.io, and Redux/ReactJS. This is the approach I'm taking:
The user connects through Socket.io as soon as he/she gets to the web app.
Through socketio-auth the user is required to authenticate and passes their username and password to the server.
Then, using socket.io-express-session, like in this example, I set a cookie with the user's username and password, so that every time they come back to the website they can be re-authenticated through socketio-auth. (I realize I could probably save a unique token in the cookie instead, would this be better?)
On the server, upon authentication, I just save their details with their socketId to the Redux store for use with every Socket.io request while the session lasts.
Assuming this is all done over SSL, is this safe? What changes would you suggest? I'm trying to make it as simple as possible yet still very safe.
It seems like point 3, with Local Storage, is the best way to go for now.
See someone else interrogation: https://github.com/hueniverse/hawk/issues/138#issuecomment-196989520
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 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.