# 2006-FSA-CH-RM-WEB-FT Cookie Jar: Cookies, Sessions, Login Flow, OAuth

[# * 1. > # cookie~****~**~~~~**~~](https://)

               _  _
             _/0\/ \_
    .-.   .-` \_/\0/ '-.
   /:::\ / ,_________,  \
  /\:::/ \  '. (:::/  `'-;
  \ `-'`\ '._ `"'"'\__    \
   `'-.  \   `)-=-=(  `,   |
       \  `-"`      `"-`   /

## This has more to do with backend validation, but for JPFP one of our ECs was to create a front-end validation for required inputs. Do you have resources for implementing backend validation(s) and relaying that information to the client?

## Answer

You can use Sequelize hooks and/or validators that before it saves or after the data comes out of the dataabse or whatever to make sure it's in a specific format that you want!

Tomorrow we will also talk about route protection where we demo access control (i.e., making sure the requester is a specific type of user (like an admin))

## Also, how can we see how many users are logged-in per Account for device limits, and reference location information for security services (like providing users warnings for new logins detected, and asking for verification etc.)?

## Answer

It'll likely use something called the [UserAgent](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent) in the request headers and [Device Fingerprinting](https://www.cookiebot.com/en/website-tracking/). With Device Fingerprinting, you can location info.

## How is sending session ID btwn server and client more secure than sending user credentials btwn server and client? It seems like, either way, you're sending infomation that gives access to user data over the internet.

## Answer

I say more secure because we are not storing sensitive information such as a password in the cookie. And you definitely shouldn't because it's generally stored as plain text. When we send data back and forth over HTTP (not HTTPS), say a password, that's available to be intercepted. Not saying, that Session stuff isn't something that can't be intercepted (our cyber instructors can talk more to it) but it's encrypted with the secret we used when we declared the session middleware.

- [Session Secret Documentation](https://www.npmjs.com/package/express-session#secret)
- [More Info on Session Secret](https://martinfowler.com/articles/session-secret.html#:~:text=A%20session%20secret%20is%20a,t%20fix%20it%20during%20production.&text=We%20can%20prevent%20this%20by%20using%20strong%20keys%20and%20careful%20key%20management.)

From the second article:
> But because these cookies are stored by the web browser (the client), the web server doesn't actually know that the cookies it receives from the client are legitimate. This guarantee is not provided by the cookie spec, which states:

> >A malicious client could alter the Cookie header before transmission, with unpredictable results

> Well that sounds bad. Later on, the spec gives us some advice:

> > Servers SHOULD encrypt and sign the contents of cookies (using whatever format the server desires) when transmitting them to the user agent

## When we delete cookies, are we clearing all the cookies? Is there data which persists for login/logout?

## Answer

If you're just logging out, then it'll clear your id from the session store so you need to login again. However, that doesn't necessarily mean all the cookies are deleted. There are tracker cookies that track you.