Quiz

1. Could we talk more about the relationship between cookies and sessions?

   Sure. Cookies allow the server to recognize a return visit. The return visit could be minutes or months later.

   The cookie can have a name=value pair, say someone's zip code. Think of a ticket/token like you get at the dry cleaner.

   Sessions are usually built on top of cookies. (There are other ways.)

   Sessions are usually from login to logout and are usually more in the minutes length, rather than months.

   Sessions require recognizing a return visit but the stakes are higher, because of authentication and authorization: who are you and what can you do.

   Think about banking websites, or even Gmail.

2. Still confused about sessions

   Hopefully the preceding helped, but please follow up if you're still confused.

3. If we don't use the Express cookie-session, can users both read and modify the data stored in cookies?

   Cookies are part of the HTTP protocol, independent of the client (browser) and the server.

   In most browsers, you can read and modify cookies. You certainly can if you build your own client, say using the Python requests module.

   The Express cookie-session is some backend software that helps Express parse and manage cookies.

   It digitally signs the cookie value so that tampering can be detected. If it's detected, the cookie is discarded, so you can trust the values you store in there.

4. I am still confused about how to digitally sign a cookie using a secret key. How will back-end verify the key?

   The software takes care of that for us automatically. But here's an outline of how the algorithm might work:

   1. Take the cookie value as plain text. Say zip=02481
   2. Take the secret value, say dilligrout
   3. Compute a secure hash of both: h=hash('zip=02481'+'dilligrout'). Suppose that value is something like h=c77504145
   4. Send the browser a cookie like zip=02481;h=c77504145

   Later, when the browser sends the cookie back to the server, we repeat the process to verify:

   1. Take the cookie value as plain text. Say zip=02481
   2. Take the secret value, say dilligrout
   3. Compute a secure hash of both: h=hash('zip=02481'+'dilligrout'). Suppose that value is something like h=c77504145
   4. Compare the hash value with the value of h that the browser sent.

   This works because of these facts:

   • The secret value is actually secret. If the Malfoy knows it, he can tamper with the cookie and create a new, valid hash value
   • The secret value doesn't leave the server.
   • The hash algorithm can't be reversed to reveal the secret value.
5. Is there a relationship between making GET/POST requests and users reading/modifying session data?

   Yes, sort of.

   We use POST when the user is modifying the state of the app, which typically means storing or updating data in the database.

   On the other hand, we would use POST for a login endpoint, where we don't update the database, but we do set values in the session.

   Also, we'll use POST today when someone adds something to their shopping cart, which is kept in the session, rather than the database.

   So, there something of a relationship, but you want to focus on whether the request is modifying the state of the app or not.

6. How do cookies work (in this class, i.e. for our final projects) with repeated user logins?

   Good question. We'll talk about passwords on Friday. You'll typically put the userid in the session when someone logs in (is authenticated).

   I don't think the number of logins affects things: we process each login the same way.

7. flash vs alerts, when would it be appropriate to use either.

   This depends on the user experience (UX) you want. Flash is less obtrusive and doesn't bring the browser to a halt, forcing the user the acknowledge it before going on. So, I think you would want to prefer flashing in most cases.

   But alert might be appropriate for very important messages, e.g. "are you sure? deleting this object cannot be un-done". (I get alerts like from Gradescope or from Github.)