Skip to content

prependToMiddlewarePriority() causes conflicts with non-Sanctum authentication systems (Sentinel in my case) #485

@elemes1

Description

@elemes1

I really appreciate this package especially the UI, its really great and it's been super useful for debugging!
This is just a small architectural concern that I think could be improved to make it work better with diverse Laravel setups.
recently came across an issue while using Log Viewer in a Laravel app that uses Cartalyst Sentinel for authentication, and ran into an issue with how the middleware priority is being configured. I wanted to report it in case it affects other users with similar setups.

The Issue

In LogViewerServiceProvider::configureMiddleware(), the package calls:

$kernel->prependToMiddlewarePriority(EnsureFrontendRequestsAreStateful::class);

This places EnsureFrontendRequestsAreStateful at the very top of Laravel's global middleware priority list, which means it runs before all other middleware including authentication middleware like Sentinel's auth checks.

This causes issues because:

  1. Global scope: The middleware priority change affects the entire application, not just Log Viewer routes
  2. Execution order conflicts: Authentication middleware (like Sentinel) needs to run in a specific order relative to session/cookie handling
  3. Duplicate session handling: When the 'web' middleware group is used (which includes StartSession), sessions get started twice in different contexts
  4. Not Sanctum-specific: EnsureFrontendRequestsAreStateful is designed for Laravel Sanctum's specific use case (differentiating between SPA and API token requests), but this package applies it globally even when Sanctum isn't being used

In my case, this was breaking Sentinel authentication because:
Sessions were being initialized at the wrong time and Cookie encryption/decryption was happening out of order

  • CSRF tokens were getting confused
  • Authentication state was being corrupted before Sentinel middleware could even run

Current Workaround

I've worked around it by extending LogViewerServiceProvider and overriding the configureMiddleware() method to do nothing:

class CustomLogViewerServiceProvider extends LogViewerServiceProvider
{
    protected function configureMiddleware(): void
    {
        // Intentionally empty - prevents global middleware priority modification
    }
}

And in my config:

'api_middleware' => [
    'web',  // Already provides session/cookie/CSRF handling
    AuthorizeLogViewer::class,
],

This works perfectly because the 'web' middleware group already includes everything that EnsureFrontendRequestsAreStateful does (session start, cookie encryption, CSRF verification).

Suggested Solutions

I think there are a few ways this could be improved:

Option 1: Remove the global priority change entirely (Recommended)

  • The middleware is already applied to Log Viewer routes via config('log-viewer.api_middleware')
  • Users who need it can configure it themselves
  • Those using the 'web' middleware group don't need it at all

Option 2: Make it conditional

protected function configureMiddleware(): void
{
    // Only modify priority if Sanctum is actually being used
    if (config('auth.guards.api.driver') === 'sanctum') {
        $kernel = app()->make(Kernel::class);
        $kernel->prependToMiddlewarePriority(EnsureFrontendRequestsAreStateful::class);
    }
}

Option 3: Use appendToMiddlewarePriority() instead

  • At least this way it runs after authentication instead of before
  • Though this still modifies global middleware, which may not be ideal

Option 4: Document it and make it opt-in

  • Add a config option like log-viewer.configure_middleware_priority
  • Default to false
  • Let users opt-in if they need it

Environment

  • Laravel: 12.x (but affects earlier versions too)
  • Log Viewer: 3.21
  • Authentication: Cartalyst Sentinel (not sure if this would affect other non-Sanctum auth, as i have only tested with sentinel)
  • PHP: 8.3

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions