Course lesson 52 · Better Auth

Protecting our API Routes

One study unit · Read, recall, then practice · Original video 00:08:42

The server now protects both tRPC calls and WebSocket connections with Hono authentication middleware. Better Auth validates the session from request headers, and the middleware stores the authenticated user ID in typed request context. That identity replaces hardcoded account values in the socket proxy and tRPC context, so each user sees their own data.

Primary source: course video 52 · Supplied English subtitles · 00:08:42.

Understand the idea

A frontend dashboard guard does not stop someone from calling its underlying API or socket endpoint directly.
Middleware runs before the route handler and either rejects the request or passes it onward with next.
The authentication route remains accessible because signed-out users need it to sign in.
Typed Hono context carries verified identity to later handlers without asking the browser to supply a trusted account ID.
The course uses one user per application account; an organization model would require different account selection.

What the course does

Attach a custom middleware to tRPC and socket routes, initially logging to verify that it runs.
Extract a helper that initializes the server-side Better Auth instance from environment configuration.
Read the session using request headers and return an unauthorized response if no authenticated user exists.
Place the user ID in Hono context and retrieve it in both protected route handlers.
Set the socket’s forwarded account header from that identity and pass it into tRPC context creation.
Deploy and verify that records associated with the old hardcoded identity are no longer listed for the signed-in user.

Watch for

The disappearance of old demo links reflects a different identity filter, not deletion of the records.
Account and user IDs are deliberately equivalent only for this course’s single-user-account model.
Added advice: every data operation must continue applying account authorization; a valid session alone does not permit access to arbitrary records.

Recall before revealing

Why should the socket’s account header come from middleware rather than browser input?

Reveal the explanation

Middleware derives it from a validated session, preventing the browser from simply selecting another account’s tracker.

Try it

Explain the expected result for a signed-out API request and a signed-in request from a different user than the demo account.

Check your result

The first is rejected; the second proceeds with its own identity and does not inherit the hardcoded demo account’s data.

Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.

Rewatch only what you need

Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.

00:00:00 — Identify unprotected tRPC and socket endpoints
00:03:02 — Apply middleware selectively
00:05:06 — Validate session from request headers
00:06:38 — User identity versus organization identity

Companion primary documentation: Better Auth basic usage. For recorded API names, commands, limits, and prices, check the version you use.

← Previous Next →