express-session

Author: rohan-paul

MongoDB/mongo-connect-npm-package-what-it-does.md

@@ -0,0 +1 @@
+[connect-mongo](https://github.com/jdesboeufs/connect-mongo) package stores MongoDB session for Express and Connect

Node-Express/bcrypt-How-it-works.md

@@ -1,3 +1,23 @@
+## Fist, What is password hashing?
+
+hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
+hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
+hash("waltz") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542
+
+Hash algorithms are one way functions. They turn any amount of data into a fixed-length "fingerprint" that cannot be reversed. They also have the property that if the input changes by even a tiny bit, the resulting hash is completely different (see the example above). This is great for protecting passwords, because we want to store passwords in a form that protects them even if the password file itself is compromised, but at the same time, we need to be able to verify that a user's password is correct.
+
+The general workflow for account registration and authentication in a hash-based account system is as follows:
+
+1> The user creates an account.
+
+2> Their password is hashed and stored in the database. At no point is the plain-text (unencrypted) password ever written to the hard drive.
+
+3> When the user attempts to login, the hash of the password they entered is checked against the hash of their real password (retrieved from the database).
+
+4> If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials.
+
+5> Steps 3 and 4 repeat every time someone tries to login to their account.
+
 ### bcrypt works in 2 steps, first genSalt and then hash the password with that salt
 
 ### The regular steps are >> Generate the salt first (if err throw err else give me the salt)
@@ -133,3 +153,42 @@ router.post('/login', (req, res) => {
 The salt is incorporated into the hash (as plaintext). The compare function simply pulls the salt out of the hash and then uses it to hash the password and perform the comparison.
 When a user logs into our system, we need to check that the password entered is correct. Unlike other systems that would decrypt the password in the database (if it is encrypted), and compare it with the one entered by the user, what we do with bcrypt is encrypt the one entered by the user. To do this, we will pass the password to bcrypt to calculate the hash, but also the password stored in the database associated with the user (hash). This is because, as mentioned before, the bcrypt algorithm used a random segment (salt) to generate the hash associated with the pasword. This was stored along with the password, and you need it to recalculate the hash of the password entered by the user and finally compare with the one entered when registering and see if they match.
 
+Looking at the [source code of bcrypt.compare](https://github.com/dcodeIO/bcrypt.js/blob/b09f7f266a7015456b7b36deeb026dc636f64542/dist/bcrypt.js#L269) function makes the above steps clear
+
+```js
+bcrypt.compare = function(s, hash, callback, progressCallback) {
+
+        function _async(callback) {
+            if (typeof s !== "string" || typeof hash !== "string") {
+                nextTick(callback.bind(this, Error("Illegal arguments: "+(typeof s)+', '+(typeof hash))));
+                return;
+            }
+            if (hash.length !== 60) {
+                nextTick(callback.bind(this, null, false));
+                return;
+            }
+            bcrypt.hash(s, hash.substr(0, 29), function(err, comp) {
+                if (err)
+                    callback(err);
+                else
+                    callback(null, safeStringCompare(comp, hash));
+            }, progressCallback);
+        }
+
+        if (callback) {
+            if (typeof callback !== 'function')
+                throw Error("Illegal callback: "+typeof(callback));
+            _async(callback);
+        } else
+            return new Promise(function(resolve, reject) {
+                _async(function(err, res) {
+                    if (err) {
+                        reject(err);
+                        return;
+                    }
+                    resolve(res);
+                });
+            });
+    };
+    ```
+

Node-Express/why-bodyParser_needed.md renamed to Node-Express/bodyParser_what-does-it-do.md

@@ -0,0 +1,45 @@
+### We use sessions to maintain state between user requests and we use cookies to transport the session ID between those requests.
+
+Every user interaction with your application is an isolated and individual request and response. The need to persist information between requests is vital for maintaining the ultimate experience for the user.
+
+After an user has authenticated, as a developer I have to retain various personalized user information that is associated with a session as well.
+
+So I have to securely set up sessions in my application to mitigate risks such as session hijacking. For that I have to obfuscate session ID’s, enforce a time-to-live in my sessions, set up secure cookies for transporting sessions, and finally the importance and role of Transport Layer Security (TLS) when it comes to using sessions.
+
+[express-session](https://www.npmjs.com/package/express-session) (https://github.com/expressjs/session ) - A very popular session module that has been highly vetted by the community and constantly improved.
+
+
+
+
+## What’s Going On Here
+
+We're importing the [session function](https://github.com/expressjs/session/blob/master/session/session.js#L24) from the express-session NPM module and passing the session function a configuration object to set properties such as:
+
+**Secret**. Required option. This is a value used in the signing of the session ID cookie, that is stored in the cookie.
+
+This can be either a string for a single secret, or an array of multiple secrets. If an array of secrets is provided, only the first element will be used to sign the session ID cookie, while all the elements will be considered when verifying the signature in requests.
+
+
+**Store**. I’m using MongoDB as my backend, and I want to persist the application sessions in my database, so I am using the connect-mongo NPM module and setting the session store value to an instance of this module. However, you might be using a different backend, so your store option could be different. The default for **store** is express-session is an in-memory storage. That is, it defaults to a new **MemoryStore** instance. ( **MemoryStore** is the default memory where express-session stores cookie data  )
+
+**Cookie**. This determines the behavior of the HTTP cookie that stores the session ID.
+
+**resave** - Forces the session to be saved back to the session store, even if the session was never modified during the request. Depending on your store this may be necessary, but it can also create race conditions where a client makes two parallel requests to your server and changes made to the session in one request may get overwritten when the other request ends, even if it made no changes (this behavior also depends on what store you're using).
+
+
+Typically, you'll want false.
+
+How do I know if this is necessary for my store? The best way to know is to check with your store if it implements the touch method. If it does, then you can safely set resave: false. If it does not implement the touch method and your store sets an expiration date on stored sessions, then you likely need resave: true.
+
+**saveUninitialized**
+Forces a session that is "uninitialized" to be saved to the store. A session is uninitialized when it is new but not modified. Choosing false is useful for implementing login sessions, reducing server storage usage, or complying with laws that require permission before setting a cookie. Choosing false will also help with race conditions where a client makes multiple parallel requests without a session.
+
+
+
+
+
+
+
+#### Good resources
+ - https://dzone.com/articles/securing-nodejs-managing-sessions-in-expressjs
+ -