As of late I have been writing some content on express.js, and as such it was only a matter of time until I came to a point where it is time to look into how to handle session data, and user authentication. If I want to implement user authentication in a way that I perceive as the right way, I will want to use passport. However so far I often find myself making simple hobby apps, as such I can take a more informal route to handling authentication involving some system that is just assignment of a unique id to each client by way of a cookie file for example. In any case this post is about express-session, a great project for working with session data in an express.js project
For a basic example of express session I made a demo that is just a single app.js file that makes use of just express, and express-session modules. The options that I give to express-session are the minimal set of options that I would want to give to any use case of express-session regardless of how simple it might be.
So for this demo I just need express-and express-session:
Once I have my demo folder set up with the package.json, and the dependences installed in the node_modules folder I just need a single app.js file at root.
I can then start the app, and go to localhost:8080 in the browser by calling app.js with node.
When I do so I should see what is in the session data object including my simple count value that will go up each time I refresh the page.
For a basic example the simple count should work at helping to show the value of express-session. It can be used to create, and update session data server side. Although The count is set back to the client via res.json, it does not have to be sent. When it comes to something that should stay server side it can, the cookie session id is the only thing that really needs to be shared.
There are at least some basic options that should always be used in most projects regardless of how simple they might be. In addition there are many other options of interest that should be set in different ways depending on the nature of the project.
This property is used to set the name of the cookie that will be sent in the response, and also read from in requests. This property can be omitted, and result in a default value of “connect.sid” Even Though it is not required, it is good practice to always give a short, concise name that is relevant to the project. Also I set a name per demo to help resolve an issue where the same cookie ends up being used for many different demos. So it is a good idea to always set unique names to eliminate cookie name collisions.
This is a required option that is used to sign cookies that are used for the sessions. The value can be a string, or an array of strings. When an array of strings is given, the string of index 0 will be used when signing session cookies, and the other strings will be considered when verifying the signature in requests.
You might be wondering if this is something that should be kept…well…secret, and the answer is of course yes. In my basic example I am just using a string literal, which is fine for a simple hello world style example, but not so great for production code.
This is another must have option that has to do with weather the session is saved to the store on every request even if it was not changed. The way I think about this I would assume that this value should be set to false with most use case examples, but it can depend on the store used. The biggest concern that comes to mind is older sates writing over newer ones because of a time race between parallel requests. Still with some stores it may be necessary to set this to true.
This is another required option that has to do with saving uninitialized sessions. When a session is new, but has not yet been modified that is an uninitialized session. My reasoning is that this should be set to false by default.
Out of the box express-session uses a mem store to store session data. This might work okay for quick demo apps, but if I do want to start going in the direction of making a production app I will want to use another storage option such as session-file-store
I can then use the file store by calling an instance of it, and setting that to the store property of the instance of express-session
To confirm that this is working I can start the app, go to localhost:8080, hit refresh a few times and then restart the app. When I go back I should continue where I left off. Also I can check out the contents of the session folder, and look at the json file that should be there, this will store the state of the session.
There are many more options for this session store, and of course there are many more options for modules that do this in a different way. For the scope of this post at least I thought that I should cover at least one of theme.
With authentication in express.js it may be best to go with passport, this is defiantly a professional and versatile way of making quick work of setting up some kind of system that involves user registration and authentication (aka logging in). However if you are just making some simple little hobby app there might be a desire to have some kind of primitive yet effective way of doing this.
If for some reason I want to parse the cookies so I can see the id values in re.cookies I can use cookie-parser module to make quick work of that.
add in cookie parser
When I use cookie parser with app.use cookie parser will populate a req.cookies array.
This module is great for getting session management out of the way quickly, I can not say that this is the kind of thing that I want to implement on my own. I did not cover all options that can be used with this module, but maybe that is a job for future posts on express. There is much more to write about with this module, as well as all the other projects that are used with it. So much to write about, and so little time.