Codecourse

What's the most confusing part of setting up Sanctum for the first time? Genuinely curious — stateful domains, CORS, the cookie handshake? It trips up a lot of developers and it's usually the same two or three things.

Laravel's CORS config only covers API routes by default. Fortify's login route is a web route. If you're hitting it from a separate client, you need to explicitly add it to the paths array in your CORS config or the preflight will block it.

The stateful domains list in config/sanctum.php tells Laravel which origins can make authenticated stateful requests. If your Nuxt client isn't in that list, requests process but carry no session state. No error thrown, just silent auth failure.

Hot take — cookie-based auth is underused in API-first Laravel apps. If you control both the frontend and backend on related domains, cookies are simpler and more secure than tokens. Tokens get stored in localStorage, cookies don't have to be. What are you using?

Sanctum's stateful auth works by issuing a session cookie. For that to work cross-origin, your SESSION_DOMAIN in .env has to match the domain your client is running on — including the port. Miss the port and requests silently fail.

The php artisan fortify:install command registers all the auth routes. Run php artisan route:list after and you'll see exactly what's available. Most developers don't check this until something breaks — worth running early.

Laravel Fortify is headless auth for Laravel. No opinions on your frontend, just endpoints. If you're building API-first with a separate client, it's a clean way to get auth routes without pulling in a full starter kit. Are you using Fortify, rolling your own, or something else?

Private channels in Laravel Broadcasting require an authenticated user. Before you write a single channel listener, Sanctum needs to be configured. Stateful domains, CORS credentials, middleware — all three have to be in place first.

We’ve released a new episode in Getting Started with Laravel: A Look Around codecourse.com/watch/getting-… This walks through a fresh Laravel install and how the structure fits together before you start building anything on top of it.

Sometimes maintainability is just choosing a data shape that the rest of the code doesn’t have to fight.

The most useful schema changes are usually the ones you stop thinking about once they’re in place.

Good backend design often looks obvious after the fact. That doesn’t make it trivial.

A clean preference model means notification classes don’t have to figure out user intent later.

This week’s refresher is up on YouTube. We’re wiring notification preferences in Laravel — pivot tables, channel storage, and a custom pivot model so the data comes back ready to use.  youtu.be/b7M3TJcJ3Ac

One of the better backend feelings is realizing the data already comes back in exactly the shape the next step needs.

The more directly the stored data maps to delivery decisions, the better the design usually is.

A relationship returning usable data instead of raw storage format is one of those small quality-of-life wins that compounds.

Without casting, channels come back as a string. With casting, they come back ready to use. That difference shows up fast.

The cleaner your relationship returns data, the less work every consumer has to do afterward.

The data may live in a pivot table. That doesn’t mean the code should treat it as second-class.