Cookies

• At a high level, a cookie is simply a piece of state (key/value pair) that the server asks the browser to store
  • Browser returns that key/value pair upon next visit to that site
• Background: The web was originally designed to be stateless; but, that can (obviously) be inconvenient.
  • HTTP itself is stateless. Any necessary state must be maintained by either the browser or the server.
• Cookies are sent in request and response headers
  • Run BasicHTTPSTransaction (which connects to wwww.gvsu.edu) and notice the Set-Cookie header
  • Open Incognito window in Chrome.
    • Visit wwww.gvsu.edu; Watch response headers
    • Reload the page. Notice request Cookie header.
• Cookie properties: https://www.php.net/manual/en/function.setcookie.php
  • name: The key in the key/value pair
  • value: The value in the key/value pair
  • expires: When the cookie expires (i.e., when the browser deletes it)
    • Sent as a UNIX timestamp (e.g., Thu, 20-Feb-2020 16:03:58 GMT )
    • Most frameworks will generate this string for you.
    • If no expires value is given, cookie expires when the browser session ends.
      • (This is one reason some web sites suggest you close your browser when finished.)
  • path: The path on the server where the cookie is available.
    • Defaults to the current path
    • If document is /Teaching/Courses/CIS371/index.html, then cookie only visible to files in /Teaching/Courses/CIS371
    • If path is set to /, then all files on server see cookie
  • domain: The (sub)domain that the cookie is available to.
    • For example, should a cookie set on cis.gvsu.edu be available to www.gvsu.edu?
  • secure: Only return cookie over HTTPS.
    • This affects browser only. It is the server’s responsibility to decide whether to send a cookie.
  • httponly: When true cookie is not accessible through JavaScript.
• To “delete” a cookie, just give it an expiration time in the past.
• Rails interface to cookies: https://api.rubyonrails.org/v6.0.2/classes/ActionDispatch/Cookies.html
  • TLDR: Treat an object named cookies as a hash.
• Express interface to cookies: https://expressjs.com/en/api.html#res.cookie
  • Best used with cookie-parser middleware https://www.npmjs.com/package/cookie-parser
• Remember:
  • Browsers don’t have to accept cookies. Avoid using them for “mission critical” features.
  • Browsers can also “lie” about cookie values. You can’t trust them.
    • For example, if you set a product price as a cookie, the client might lower that price when visiting the site again.
• Tracking:
  • How do cookies get abused?
    • Remember, cookies are stored by domain. Suppose both cutekittens.com and petlife.com both contain an image tag with a source of eviltracker.com. Then any cookies set when visiting site will be returned when visiting the second. The tracker than then tell that a single user visited both sites. (This is how you can shop for something on Amazon then have ads pop up elsewhere.)
    • This is what is meant by “third-party cookies”: You visit a.com and get asked to save/send a cookie from b.com that has some kind of embedded content.

Session

• HTTP itself is stateless; but the server doesn’t have to be.
  • Clear example: Servers that store data in a database.
• The server can remember a user’s data; but still needs some way of reliably knowing who the user is during each request.
  • Don’t want users to be able to easily fake their identity.
• Basic idea:
  • Server sends a cookie with a long random string.
  • That long, random string is a key to a set of data for that particular user.
  • When the user visits another page, the cookie is returned and matched up with the data.
  • Make sure string is long and random enough that it can’t be guessed.
• Rails automatically sets up a session for you (whether you need one or not)
  • Session data is stored in a special hash named session
    • For example, you can save the current user’s ID once she has logged in.
  • By default, this data is sent in an encrypted cookie with every page.
  • Because data is encrypted, you can trust that it hasn’t been modified
  • call reset_session when necessary.
  • Storing the session in the cookie is easiest, but you can also
    • Store it in server memory (e.g., using memcache)
    • Store it in a database.
    • See https://www.justinweiss.com/articles/how-rails-sessions-work/ for details
• To use sessions in Express, install the express-session package
  • https://www.npmjs.com/package/express-session
  • This package stores session data on the server not in a cookie.
  • If you do store session data in a cookie (which you shouldn’t), make sure the cookie is secure (i.e., encrypted) so that it is obvious if a user modifies it.