fix(broadcasting): Exclude CSRF verification from broadcast auth routes

[binaryfire]

Problem

Broadcasting authentication routes (/broadcasting/auth and /broadcasting/user-auth) fail with TokenMismatchException when VerifyCsrfToken middleware is included in the web middleware group.

These routes receive POST requests from Pusher/Soketi JavaScript clients during private/presence channel authentication. The JavaScript client has no awareness of Hypervel's CSRF protection system and cannot include CSRF tokens in its requests.

Solution

Exclude broadcasting routes from CSRF verification by calling VerifyCsrfToken::except() when routes are registered.

Laravel's implementation:

• https://github.com/laravel/framework/blob/12.x/src/Illuminate/Broadcasting/BroadcastManager.php#L81
• https://github.com/laravel/framework/blob/12.x/src/Illuminate/Broadcasting/BroadcastManager.php#L103

Laravel uses ->withoutMiddleware(VerifyCsrfToken::class) on both routes. However, this can't be ported to Hypervel because the without_middleware route option operates at a different stage in the middleware resolution process:

Framework	When exclusion is applied
Laravel	After middleware groups are expanded (e.g., 'web' → [StartSession, VerifyCsrfToken, ...])
Hypervel	Before group expansion, so array_diff(['web'], [VerifyCsrfToken::class]) has no effect

Since Hypervel's route-level exclusion can't remove middleware from inside groups, we use VerifyCsrfToken::except() which adds paths to the middleware's internal exclusion list.

Why This Matters

For CSRF protection to work properly, VerifyCsrfToken must be in the web middleware group. However, this causes broadcasting authentication to fail:

1. User visits page → session started, CSRF token generated
2. Page connects to Pusher/Soketi WebSocket
3. Pusher client POSTs to /broadcasting/auth to authenticate private channel
4. VerifyCsrfToken middleware rejects the request (no CSRF token)
5. Channel authentication fails

The fix ensures broadcasting routes can continue to use the web middleware stack (for session/auth) while being excluded from CSRF verification.

Changes

• Added VerifyCsrfToken::except(['broadcasting/auth']) in routes()
• Added VerifyCsrfToken::except(['broadcasting/user-auth']) in userRoutes()
• Added tests to verify paths are excluded from CSRF verification

[binaryfire]

Hi @albertcht. I suggest taking a look at #295 first. If that gets merged, then we can remove the middleware from the broadcast routes using without_middleware, which would be cleaner

[Copilot]

Pull request overview

This PR fixes a TokenMismatchException that occurs when broadcasting authentication routes are accessed by Pusher/Soketi JavaScript clients. The clients cannot include CSRF tokens in their authentication requests, so these routes must be explicitly excluded from CSRF verification.

Key Changes:

• Exclude broadcasting/auth and broadcasting/user-auth routes from CSRF verification using VerifyCsrfToken::except()
• Add comprehensive tests to verify the CSRF exclusion behavior
• Add cleanup in test tearDown to flush static CSRF state

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/broadcasting/src/BroadcastManager.php	Added CSRF exclusions for broadcasting authentication routes in both routes() and userRoutes() methods with explanatory comments
tests/Broadcasting/BroadcastManagerTest.php	Added two new test cases to verify CSRF exclusions work correctly, plus static state cleanup in tearDown

---

After thoroughly reviewing the code changes, implementation, and tests, I found no issues with this pull request. The implementation is well-designed, properly tested, and correctly handles the static state management of the CSRF exclusion list. The solution appropriately addresses the problem described in the PR description.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.