Login session

[jzunigarce]

For login via website, session(cookies) or token will be stored?

[gbowne1]

We have plenty of resources and browser API's available to us by the browser alone, localstorage, cookies, session, indexeddb, etc. I would like to make use of as many of them as we can, keeping in mind security, performance, etc.

[jzunigarce]

Currently the page communicates to the server via round-trip, you would like all data requests (excluding page requests) to arrive via API(POST /api/v1/dashboard) or to stay as it is currently(POST /dashboard) . This for the app we are working on

[gbowne1]

So I wrote this note a while back for use in all my projects.

For login via website, you have the option of using session (cookies) or token. Both have their own advantages and disadvantages.

Session-based login: When a user logs in, the server creates a session and stores the session data on the server-side. The session data is then used to authenticate the user for each subsequent request. The session ID is stored as a cookie on the client-side.

Token-based login: When a user logs in, the server creates a JSON Web Token (JWT) and sends it to the client. The client stores the token (usually in local storage or a cookie) and sends it back to the server for each subsequent request. The server then verifies the token to authenticate the user.

Some advantages of session-based login are that it is easy to implement and it provides server-side control over user sessions. Some disadvantages are that it requires server storage for session data and it is vulnerable to session hijacking attacks.

Some advantages of token-based login are that it is stateless, meaning the server does not need to store any session data. It is also more secure than session-based login because it is not vulnerable to session hijacking attacks. Some disadvantages are that it requires more work to implement and it can be vulnerable to Cross-Site Scripting (XSS) attacks if not implemented properly. [0]

You can also use local storage, cookies, session, indexeddb, etc. for storing data. Local storage and cookies are both client-side storage options while session storage is server-side. IndexedDB is a client-side storage option that supports larger amounts of structured data.

Local storage is a simple way to store key/value pairs in the client's browser. It is persistent and can be accessed across browser sessions. Some drawbacks are that it is limited to 5-10MB per domain and is not secure for storing sensitive data.

Cookies are small text files that are stored on the client's browser. They can be used to store small amounts of data that can be accessed across browser sessions. Some drawbacks are that they have size limitations (4KB), are vulnerable to Cross-Site Scripting (XSS) attacks, and can be slow to transmit over the network.

Session storage is similar to local storage but is stored on the server-side. It can be used to store larger amounts of data and is more secure than local storage. Some drawbacks are that it requires server-side storage and can be slower than local storage.

IndexedDB is a client-side NoSQL database that supports larger amounts of structured data. It is more powerful than local storage but is more complex to use. Some drawbacks are that it is not supported in all browsers and requires more work to implement. [1]

It is recommended to use API endpoints for data requests because it follows the RESTful architecture pattern and separates the concerns of the client-side and server-side. This allows for better scalability and maintainability of the application.

API endpoints also allow for better security because they can be authenticated and authorized separately from the client-side. This means that sensitive data and operations can be protected from unauthorized access.

On the other hand, making round trips to the server for data requests can be slower and less efficient than using API endpoints. It can also make the code harder to maintain because the client-side is tightly coupled with the server-side. See: (https://larswaechter.dev/blog/nodejs-rest-api-structure/)

In conclusion, for login via website, you have the option of using session-based or token-based login. It is recommended to use API endpoints for data requests because it follows the RESTful architecture pattern and allows for better scalability and maintainability of the application. You can also use local storage, cookies, session storage, or IndexedDB for storing data, each with their own advantages and disadvantages. It is important to consider security and performance when choosing a storage option

[jzunigarce]

If we use login via token, we need create a API, i will modify the source for implement. I will return a token when you signin

[gbowne1]

Knowing all this, I think the best thing would be API endpoint. We can then store data that does not need to be in a special database using the browser storage stuff like IndexedDB, LocalStorage, Session, etc. and it doesn't need a ton of payload to do so.

[gbowne1]

@jzunigarce how did you get Postman set up?

[gbowne1]

@jzunigarce we have a check mark box in the login panel of the login page.

I was considering `cookle-session' so that the checkbox might have some functionality in the context

It's hard to tell but we should think about implementing proper security measures to prevent unauthorized access to user accounts, such as using HTTPS, hashing and salting passwords, and validating user input on the server side. Additionally, should provide users with a way to log out of their accounts and clear any stored authentication tokens or cookies.

We would in the app.

const cookieSession = require('cookie-session');

app.use(cookieSession({
    name: 'session',
    keys: ['key1', 'key2'],
    maxAge:  60 * 1000
}));

login route:

app.post('/login', (req, res) => {
  const { email, password, remember } = req.body;

  // Authenticate user
  // ...

  // Set session cookie
  req.session.user = { email };
  if (remember) {
    req.session.cookie.maxAge = 30 * 24 * 60 * 60 * 1000; // 30 days
  }

  res.redirect('/dashboard');
});

Validating the DOM of the checkbox is something like (likely in app.js):

const loginForm = document.getElementById('login-form');
const rememberCheckbox = document.getElementById('remember-checkbox');

loginForm.addEventListener('submit', (event) => {
  if (!rememberCheckbox.checked) {
    event.preventDefault();
    alert('Please check the "Keep me logged in" box to proceed.');
  }
});

So, basically we gett he "keep me logged in" function as a feature that allows a user to remain logged into a website or application for an extended period of time, even after they close their browser or navigate away from the site. This is typically achieved by storing a cookie on the user's device that contains a session token or other identifier that can be used to authenticate the user on subsequent visits.

The purpose of this feature is to provide convenience for users who frequently access the same site or application, as it eliminates the need to repeatedly enter login credentials. However, it's important to note that this feature can also pose security risks, particularly if the user is accessing the site from a public or shared device.

"Keep me logged in" is often confused with "remember me" or "stay signed in" functionality, which are similar but not identical. "Remember me" typically remembers the user's email address or username, so they only need to enter their password on subsequent visits. "Stay signed in" means that the user's session token is preserved with a very long expiration time and won't automatically be cleared out when the user closes their browser.