We Keep Coding

Express Js: req.session vs cookie vs local storage vs session storage

I am new to Express JS and frontend. I am developing an app which is using req.session for maintaining the user session and local storage for storing some other temporary info.
I have seen various articles for differences between the above but I am still unclear which is used when and how long does each persists.
According to me:
1.req.session: The server maintains this session. This gets cleared when user clears cookies.
2.cookies: Cookies are sent to server to maintain authentication
3.local storage: This persists till user deletes the cookies?
session storage: This is maintained by browser and persists for one tab.

All are different type of storage mechanisms commonly use in web application development.
But The matter is choosing the correct one.
In Short
Cookie Storage
Cookie is a browser storage mechanism, But can access from server-side through request. Developers use cookies to store data which should be accessible from server and client.
Example: Authentication Tokens, Analytical Data
Session
Session storage is a server-side storage mechanism which can be only accessed by server. So we cannot access from browser directly. Use sessions to store confidential information.
Data in session will be destroyed when the session is closed.
Local Storage
Local Storage is like Cookie BUT we cannot access from server, we can store much more data than cookies and it doesn't expire unless we clear.
Cookies - 4 KB &
Local Storage - 5 MB
Session Storage
Session Storage is similar to Local Storage. But the only difference is, Local Storage doesn't expire But Session storage will be destroyed when page session ends. Session storage keeps different session per page (tabs)

I'll go through each of your points and discuss them...
1) req.session: The server maintains this session. This gets cleared when user clears cookies.
If you're keeping this in a persistent store (disk-backed data store), you can keep this state for as long as you want. The server will lose track of the client that it corresponds to when the user clears their cookies. Depending upon how you manage your persistent user storage, you may be able to rebuild a previous session object when the user logs back in again (allowing you to use their userid to find their lasting state in your database, create a new session cookie, build a new session object from that and reconnect that browser with a new session object).
2) cookies: Cookies are sent to server to maintain authentication
That's an over simplification of the utility of cookies. Cookies allow a server to set some state in the user's browser that will be presented back to the server with each request from that specific browser. Cookies are often used for keeping track of an authenticated client and often used for keeping a key to a server-side session object. There are thousands of other things cookies can be used for too (user site preferences, tracking ids, other user state, etc...).
3) local storage: This persists till user deletes the cookies?
Browser local storage has no connection at all with cookies. It is a separate local data store in the browser that is accessible only to client-side Javascript in a web page. Deleting cookies has nothing to do with deleting local storage. They are separate items that can be separately retained or deleted. The server has no access at all to local storage. In addition, local storage is segmented so that the local storage values form one web site cannot be accessed by Javascript in pages from another site.
4) session storage: This is maintained by browser and persists for one tab.
It's not quite clear what you mean by "session storage". There are "session cookies" which are purposely designated upon creation to only persist while a given browser is running. If the browser exists and then some time later is restarted, any session cookies will be gone. Their purpose is generally for short term cookies, not meant to persist beyond what the user is currently doing.
One other possible thing you might have meant by session storage is long term, persistent storage on the server (typically in a database on disk) for various user properties or state that you want to last a long time. Imagine the user populates a shopping cart and you want them to be able to keep that shopping cart indefinitely as they move from device to device and as they add/remove things from it over a significant amount of time. For these types of things, you won't typically rely on a session object to keep track of these, but will use a database as the main source of that data. It's possible some subset of data currently being worked on might be cached in a server-side session object, but that would only be for expediency, not as the long term storage for it.
Or perhaps you meant Window.sessionStorage in the browser. That works like localStorage, but only persists for the duration of the browser being open (similar lifetime to session cookies) and unlike localStorage, each tab or window has its own sessionStorage. Like localStorage, each origin has its own sessionStorage some a page from one origin can't access the sessionStorage for a page from a different origin, even if they were both loaded into the same window/tab.
In order to help you more specifically with your application, we would have to understand each piece of state you wanted to keep track of and what it was used for. Only then could we suggest what mechanism might be best for storing it.

req.session
When a user visits the site, it creates a new session object for the user and assigns them a cookie.
Whenever the user request from the same client again, the cookie is checked, sent to the server for processing and the session information stored is updated.
The difference between Cookies, Local Storage(LS) and Session Storage(SS) is as follows.
Cookies is processed server side, while LS and SS data is never sent to server. They are stored locally.
Storage capacity of a Cookie is max 4 KB, while for LS and SS is more than 5 MB.
Cookies mostly store only the session id. While LS and SS can store more information like user information or page browsing history.
SS gets cleared when a user closes tab(session ends). While Cookies can be deleted by clearing cookies and LS can be cleared by deleting Browser cache.
I will update the answer if I remembered anything else.

Send JWT token to server upon initial browser request (using local storage)

Okay, let's say I have a login page where when the user logs in he or she gets a JWT token from the server which is then saved in local storage (I know cookies is better but I want to do it with local storage). After that, imagine I quit my browser (token is still in local storage and in this example has no expiration date). Now what I want is the following: After quitting the browser (but I got successfully logged in and have token in local storage) how do I make it so that upon initial request to the same server I don't get the login page up again but instead have the user already signed in? Taje into an account that I am able to authenticate the user after the first request and I am aware how but How do I send the token in the initial request?

There may not be a direct solution to your requirement.
But, One hack can be added by adding Script in Head tag.
And withing this script you check if localStorage.getItem('key') is present or not.
If value is present send the request to Home Page directly along with Token or else Login Page.
But, this script download is extra server round-trip.

Persistent user session using AWS Cognito in Electron

Making a AWS Cognito user session persistent in Electron
AWS Cognito stores the current user session in the localStorage. While the user session is present in localStorage after the user has logged in, localStorage isn't persistant in Electron - so when the application restarts, the user session is gone and the user has to log in again. Normally the user session would be recieved from localStorage, since it is persistent in browsers.
I know that one can use electron-json-storage to store data persistantly in Electron and generally in node applications, but since AWS cognito uses localStorage, I am only able to use an approach that would change localStorage into being persistant, i.e redirected to a file storage.
I have tried node-localstorage which works, but cognito still uses the localStorage from the browser, even when global.localStorage is set.
I know that the userPool can be passed a {Storage: ...} object to use that as storage, but it still used the original localStorage, when I passed the node-localstorage to it.
TLDR;
How can I make the AWS Cognito user session persistent in electron?
If possible, can I replace localStorage with node-localstorage globally, so that AWS Cognito will use it?

Cognito will be giving you three tokens idToken, accessToken and refreshToken
A simple idea will be to save the refreshToken in your localstorage that you think is persistence. and on electron app start use that refreshToken to authenticate user user on Cognito.

Is it possible to fake a session in PHP by setting cookies on client side using JS?

Supposedly, I am not using HttpOnly cookies for my session on a PHP web app. If a visitor is on a page that uses PHP sessions, they can see the session cookies. In addition to viewing, they can also delete or edit it.
The next case involves the user being on a page (say, normal page) on my web app that doesn't uses sessions and the normal page contains a link to a page which uses sessions (session page), having, session_start(). On the normal page, if a cookie is set (say using the console) with the same name as the one I use for session page, and the click is made on the link to the session page, what happens when I do session_start() on the session page?
Does it create a new session, or tries and map to a session with the value in the cookie being sent from the normal page?
If it maps, to an existing session value, then the session is said to be hijacked. What happens in the case when it doesn't map? Does it create a session cookie with a new value?
Even if I use HttpOnly for my sessions, it is sure that the session cookie cannot be read or manipulated using JS on the client side. But on the server, does the server read the same (HttpOnly) on the session cookie being sent to the server by the client and invalidates the session, in case it wasn't HttpOnly? Or does it try to map the value to existing sessions on the server?
Hope I was able to make it clear.

Sessions work in PHP like this.
When the user first visits the site and the PHP has session_start() it checks if the user is sending a cookie with a session ID. If they aren't then it creates one and sends it so the user stores it in a cookie. Then when the user visits another page session_start() can check if they already have a cookie and this time they do. Session cookies (stored on a user pc) are cleared when the browser is closed.
session_start() isn't creating a new session every time it is called. What it is doing is pulling in information about that session so it can be used further down in the code. When the user sends the session ID from their cookie, session_start() then pulls in the information stored about this session from the web server so then you can do things such as if you stored adminloggedin as true or false in their session. If the user didn't send a session ID then it doesn't pull any information from the server and just creates an ID and sends this back to the user to store in a cookie.
You don't need to use session_start() on every page however if you needed to check something from a users session such as if they are logged in then you need to call it in order to get the data about their session.
All information about a session is stored server side. For example, if I said the user was logged in and stored this in the session then this can be checked to allow access to admin pages. The user cannot fake this as all they are sending is the session ID and all the data about the session is stored server-side. They are not storing a cookie with information about the session, all they store is the ID for the session which is sent across.

browser refresh - lost servicestack authentication session data

I have an angular.js single page app that authenticates against a RESTful API (Servicestack). This all works fine. When the response from the authentication api is returned the username is stored on an Angular service and an isAuthenticated flag is set to true.
Any requests against an [Authenticate] attributed web service then returns data.
My issue is that when I refresh the browser my javascript angular objects are flushed and the fact the user authenticated is forgotten. Yet when I call the [Authenticate] attributed service they work correctly because the session is still live...
Apologies for the rather noob question but how does the browser pass the session to the web service when the javascript objects have been destroyed and recreated? How do I grab the same session on refresh and set my Angular service up with the username etc.?

ServiceStack Authentication uses cookies to store the session token by default. Which means your Angular application will receive the cookie when you first sign in. It will pass this for subsequent requests, and they will succeed while the session is still valid on the server.
The problem will be that Angular will lose the object state, when you refresh the page, that is telling it you have an active session. So you must restore this knowledge to Angular. There are two ways to tackle this:
Check for the ss-id cookie when you application starts and assume you have a valid session. In other words, so restore to a signed in state, until you get a 401 error from the server. This is the quickest approach, and doesn't require additional overhead to check the session if somebody refreshes the page.
Check for the ss-id cookie and make a test authenticated request to check the session is still valid.
If you need to restore other information such as the current logged in user's name etc, then you would need to store that in a cookie/local storage to restore it on refresh, or go with method 2, and retrieve it back from the server.
You can use $cookies provider to manage the session cookie.