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

What Are Sessions?

An authenticated session is created when a user successfully logs in. It's a record stored on the server that says "When a user presents this session ID, let them access this account while the session is valid."

In a typical browser flow, the client stores and sends that ID in a cookie, and the server re-checks it against the session in the database on every request.

Session IDs

A session ID is a reference to server-side data (often a row in a sessions table) that stores:

A unique ID for the session (id, which is secret and given to the client)
Which user authenticated (user_id)
When the session expires (expires_at)
Whether the session has been revoked (revoked_at, can be NULL if the session is still valid)

For each request, the server reads the session ID from the Cookie header, looks up the record, and rejects sessions that are missing, expired, or revoked.

A session ID is a bearer credential, so it needs to stay secret. Don't put raw session IDs in URLs or logs.

Assignment

Bearly Secure uses sessions to protect the user account page. To confirm that things are working correctly, let's have the app log a message whenever an authenticated user reaches that page.

Add an account_accessed log event to the GET /account route.

Update the GET /account route in src/routes/account.ts:
1. If the user has a valid current session, before rendering the account page, call the provided logEvent function with the event name "account_accessed".
2. Include the current user's userId and email, and the session's expiresAt, in the log event.
  
  Ensure invalid sessions still redirect to /login without writing the account_accessed event.
Manually test the change:
1. Reset and then re-start the app.
2. Visit http://localhost:3000/account in your browser. It should redirect you to the login page.
3. Log in with a test account:
  - Email: [email protected]
  - Password: password123
4. Navigate back to /account by clicking the "Hello, Mabel Pines" link in the top nav.
5. Scroll to the bottom of the account page to see the session card.

Verify the data/bearly-secure.log file exists and has at least one entry for the "account_accessed" event:

{
  "timestamp": "2026-08-13T19:31:24.639Z",
  "event": "account_accessed",
  "userId": 1,
  "email": "[email protected]",
  "expiresAt": "2026-09-12T19:31:20.138Z"
}

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