This lesson's interactive features are locked, please to keep using them

What Are Cookies?

Cookies are small name-value pairs that a browser stores and sends with matching HTTP requests. Many web applications happen to store session IDs in cookies, but they're totally different concepts. A cookie contains:

A name, like: bootdev_session_id
A value, like: 7f3c9a21d84e4b6fa2c18e57b9034d6a
Optional attributes like:
- Secure (sent only over HTTPS, with a localhost exception)
- HttpOnly (unavailable to document.cookie)
- SameSite (restricts cross-site sending)

Aside from session IDs, cookies are used for stuff like preferences, shopping carts, and yes, tracking. For example, the Google Analytics cookie's name is _ga and has a unique value like GA1.1.1734567890.1723927600.

When a server sends a valid cookie, the browser automatically stores it and attaches it to future requests that match the cookie's scope and security attributes. Your client-side code doesn't need to muck with the cookie at all! The server sets it in a response header, and the browser echoes it back in future request headers.

Servers create cookies with the Set-Cookie response header:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: bootdev_session_id=7f3c9a21d84e4b6fa2c18e57b9034d6a; Secure; HttpOnly; SameSite=Lax

Browsers then attach the cookie to matching requests with the Cookie request header:

GET /account HTTP/1.1
Host: localhost:3030
Cookie: bootdev_session_id=7f3c9a21d84e4b6fa2c18e57b9034d6a

Full Cookie Auth Flow

The user logs in with their username and password.
The server verifies the credentials and creates a session for that user.
The server sends a response with a Set-Cookie header with the session ID.
The browser stores the cookie.
The user makes a request to post a comment, and the browser automatically sends the session cookie with the request.
The server reads the cookie, loads the session, and checks that it's still valid. If it is, the hot-take is posted.

Assignment

Bearly Secure creates a server-side session with an expiration time, but the browser cookie currently does not include that expiration. Let's make the cookie and the session record agree!

Update the shared session_id cookie helper so the cookie expires when the server-side session expires.

In internal/auth/sessions/sessions.go, update SetCookie so the http.Cookie expiration matches session.ExpiresAt.
Test the changes:
1. Reset and restart the app.
2. Log in as Mabel Pines.
3. Open your browser's developer tools (right-click the page and select Inspect). In a Chromium-based browser, open Application > Storage > Cookies > http://localhost:3030.
4. Confirm that the session_id cookie shows an explicit expiration date:
```
Expires / Max-Age:"Sat, 12 Sep 2026 20:49:48 GMT"
```

With Bearly Secure still running, run and submit the CLI tests from the project root.