Statamic Logbook Laravel Package

Getting Started

Install and confirm the dependency floor

composer require <vendor>/<package>:^4.1
composer show rap2hpoutre/laravel-log-viewer   # expect 3.x after this release

v4.1.0's only change is widening the constraint on rap2hpoutre/laravel-log-viewer from ^2.x to ^3.0. That is a two-for-one: Laravel 13 compatibility plus the upstream RCE fix. If you were previously stuck on the log viewer 2.x line (or on Laravel 12 because of it), this release is what unblocks you — run composer update rap2hpoutre/laravel-log-viewer <vendor>/<package> rather than a bare composer update so you can see exactly what moved.

Where to look first

1. config/<package>.php — publish it (php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider") and read the log-viewer block: storage path, log file pattern, route prefix, middleware.
2. The service provider — find where the viewer routes are registered and what middleware stack they inherit.
3. composer.lock — verify you actually resolved 3.x; a stale lock will silently keep you on the vulnerable 2.x.

First use case: boot the app in local, hit the configured log route (commonly /logs), and confirm you can tail storage/logs/laravel.log without shell access. That is the day-to-day value: reading a stack trace from a browser, on a machine or container where you don't have SSH, while reproducing a bug.

Implementation Patterns

Lock the route down explicitly. The viewer is a file-reader behind an HTTP route. Register it only outside production, or gate it:

// AppServiceProvider::boot()
if (! app()->isProduction()) {
    // package routes already registered
} else {
    // or gate them
    Gate::define('viewLogs', fn (User $u) => $u->isAdmin());
}

Then set the middleware in the published config rather than editing vendor routes:

'middleware' => ['web', 'auth', 'can:viewLogs'],
'route_prefix' => 'admin/logs',

Treat it as an internal ops surface, not a user feature. The healthy pattern in teams using this: the log viewer route lives under the same auth guard as your admin area, is excluded from sitemaps and public route listings, and is behind whatever IP allowlist or basic-auth you already apply to staging.

Version-constraint hygiene. Because the package declares ^3.0 (not >=3.0), you get 3.x patches automatically and are protected from an unexpected 4.x. If you still support Laravel 11/12 on a shared codebase, check the viewer 3.x requirements before bumping the parent package — 3.x's own illuminate/* constraints are what determine whether this release is safe for your oldest supported framework version. Run the full test matrix, not just the newest Laravel job.

Pair it with structured logging. The viewer is a convenience layer over storage/logs/*.log. Keep writing through Laravel's normal channels; use the viewer to read, and use Log::channel('daily') naming so the file-pattern config matches. Multi-channel setups (daily logs, per-tenant files) usually need the pattern glob widened in config, not code changes.

Gotchas and Tips

The RCE fix is the reason to care. Upstream 3.0 addresses a remote code execution issue in the log viewer. If your application ships this route anywhere reachable, staying on 2.x is a live vulnerability. After updating, confirm with composer show / composer why rap2hpoutre/laravel-log-viewer that 3.x is resolved — and if another dependency pins ^2.0, you'll need to resolve that conflict (composer why-not rap2hpoutre/laravel-log-viewer 3.0) rather than forcing it.

Don't trust composer update alone. Constraint relaxations are the classic case where the lockfile doesn't move because nothing else forced a re-resolution. Explicitly update the sub-dependency and review the diff.

Config caching will bite you. After publishing or editing the config, run php artisan config:clear locally (or config:cache in deploy). A stale cached config pointing at the old route prefix/middleware is the most common "the change did nothing" report.

File permissions, not code, cause most blank pages. The PHP process needs read access to storage/logs and the files inside. Container images that write logs as root and serve as www-data will render an empty viewer with no error. Check storage/logs ownership before debugging the package.

Large logs will time out. A multi-hundred-megabyte laravel.log can exhaust memory or hit max_execution_time when the viewer tries to render it. Rotate (daily channel, or logrotate) and keep the viewer scoped to recent files; consider limiting the pattern to *.log and excluding archives.

Logs contain secrets. Session IDs, tokens, full request bodies, and PII routinely land in stack traces. This is the strongest argument for local-only or strictly-gated access — the viewer turns your log file into a browsable web page, and the upstream RCE fix doesn't change that exposure.

Extension points: override the package's published views (custom layout/branding), point the viewer at a different disk path for containerised setups where logs are mounted elsewhere, and swap the middleware in config instead of patching the service provider — patching vendor code means this update, and every future one, becomes a manual merge.