Access control (Laravel)

When Log Lens is mounted inside a Laravel app, access is decided by your app's own authentication - there is no separate API key. Every dashboard and API route passes through one authorization gate before it runs.

Default behavior

With nothing configured:

Environment	Access
local	Open to anyone who can reach the URL (including an unauthenticated tab).
any other (production, staging, ...)	Denied to everyone.

This means a fresh install is never exposed unauthenticated in production, but it is open in local - set a rule below if you want to require login even locally.

Method 1 - the auth callback (recommended)

Register a callback in a service provider's boot() (e.g. app/Providers/AppServiceProvider.php). Return true to allow.

use LogLens\Laravel\LogLens;

public function boot(): void
{
    LogLens::auth(function ($request) {
        return $request->user() !== null; // any authenticated user
    });
    // Note: a rule this broad makes every logged-in user a Log Lens *owner*
    // unless you also lower `log-lens.default-role`. See "Production checklist".
}

Common variations:

// Restrict to specific people by email
LogLens::auth(fn ($request) => $request->user()
    && in_array($request->user()->email, ['you@example.com']));

// A role (spatie/laravel-permission)
LogLens::auth(fn ($request) => $request->user()?->hasRole('admin') ?? false);

// A permission
LogLens::auth(fn ($request) => $request->user()?->can('view-logs') ?? false);

// A Gate/policy you already defined
LogLens::auth(fn ($request) => $request->user() !== null
    && Gate::forUser($request->user())->allows('view-logs'));

The callback receives the current Illuminate\Http\Request. When it returns false the visitor gets a 403.

Method 2 - a Laravel Gate

If no callback is registered, Log Lens looks for a viewLogLens gate. Define it in a service provider:

use Illuminate\Support\Facades\Gate;

Gate::define('viewLogLens', function ($user) {
    return $user?->can('view-logs') ?? false;
});

The $user is nullable, so you can decide whether guests are ever allowed.

Method 3 - route middleware

Add authentication middleware to the route group in config/log-lens.php. This runs before the gate, so unauthenticated visitors are redirected to login rather than seeing a 403:

'middleware' => ['web', 'auth'],

Use ['web', 'auth', 'can:view-logs'] to combine login with an ability.

Turning it off entirely

Set an environment variable to unregister every Log Lens route - a hard kill-switch independent of the gate:

LOG_LENS_ENABLED=false

Standalone deployments

The standalone (non-Laravel) app doesn't use these hooks - it protects the API with a shared key instead. See API key authentication and Require login or an API key.

Production checklist

• Register an auth rule (Method 1, 2, or 3) - don't rely on the local default.
• Serve over HTTPS behind your app's normal stack.
• Prefer a specific rule (role/permission/allowlist) over "any authenticated user" if the dashboard exposes sensitive log data.
• Decide what a permitted user may do: everyone this gate admits is an owner by default — settings, plugins, connector credentials, provisioning applications, deleting data. Set LOG_LENS_DEFAULT_ROLE=editor (or viewer) and grant owner deliberately via log-lens.identity. See Roles & assignment.
• Consider LOG_LENS_ENABLED=false in environments where it should never appear.

See also: The Laravel adapter · Cross-origin protection / Security.