07-cookie-dough-(raw-cookies)-***••(ruby,webdev)

7. Cookie Dough (Raw Cookies)

Anyone who's ever made a website before knows that cookies are how you're supposed to implement login. Cookies even sometimes have a bad reputation: Some security-minded folk say that cookies are bad, and can be used to track your identity, spy on you, and show you ads. Under GDPR, businesses are required to show you a notice about cookies, these notices are all over the Internet.

Cookies can seem magical. Web frameworks encapsulate cookies inside of authentication or "session" systems, and web browsers save, send, and manage cookies without a peep to the user.

What are cookies, actually?

Cookies are another contract between a web server and a web browser¹. They're a way for the server to store information about the browsing session inside of the browser. The browser then must send that information back to the server in subsequent requests, essentially giving the browsing session "state" that persists across page loads.

The HTTP cookie protocol consists of two headers:

• Set-Cookie (Response header)

  The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

  Example:

  Set-Cookie: sessionId=38afes7a8

• Cookie (Request header)

  The Cookie HTTP request header contains stored HTTP cookies previously sent by the server with the Set-Cookie header.

  Example:

  Cookie: sessionId=38afes7a8

Cookies are stored in a key-value fashion inside the browser, and sent back to the server on each request. They also eventually expire, though that can be controlled by the expires and Max-Age directives. After cookies expire, the browser is supposed to delete them.

WTF?

Cookies have a special power. They can be enormously confusing. Probably partly because they're called "cookies," which isn't the most descriptive name¹. Web browsers hide them from you deep inside the Developer menu. And they're already confusing, so web frameworks hide them inside the authentication or session systems.

Sometimes you just have to go deep to get a feel of what's going on.

Assignment

Continue working on the raw Rack-converted BELP from 6. Continuing To Deconstruct The Framework. Remove the Rack::Session::Cookie middleware from the project. As soon as you do that, user login will stop working. Use the Set-Cookie response header, and the Cookie request header to store enough information about the user (why not their ID?) to identify them from request to request.

The BELP company's investors want to see user engagement, and that means keeping the user logged in forever. By default, cookies expire after quitting the browser. Use the directives for the cookies that last forever.

Extra Credit (If the assignment is too short)

• Is your website secure or not? If not, how could you make it secure?
• Does the BELP code now seem messier? If so, see if you can figure out a way to clean up the code.

---

¹ Not entirely true because cookies can also be set from JavaScript. But that's not important for this lesson.

² though admittedly cute