Log Viewer Bundle Laravel Package

Getting Started

Reality check before you install anything: itn/log-viewer-bundle is a Symfony 2 bundle, not a Laravel package. There is no service provider, no facade, no Artisan command, and no config/log-viewer.php. composer require itn/log-viewer-bundle in a modern Laravel app will fail dependency resolution (Symfony 2 / PHP 5.x constraints) or, if forced, pull in a package that expects an AppKernel, Symfony\Bundle\FrameworkBundle, and Resources/config/routing.yml — none of which exist in Laravel. Nothing will auto-register.

Where to look first (if you're evaluating it against a legacy Symfony 2 app):

1. composer.json — confirm the symfony/symfony and PHP constraints. This is the go/no-go gate.
2. The bundle class (typically ITNLogViewerBundle.php) — what you'd register in AppKernel::registerBundles().
3. Resources/config/routing.yml — the single route it exposes.
4. Controller/ and Resources/views/ — the actual behavior: it globs a log directory and renders file contents into a Twig template.

First use case: register the bundle, import its routing, hit the route in a browser, and read app/logs/dev.log without SSH. That is the entire value proposition — a read-only web UI over text log files. Nothing more.

What a Laravel developer should actually do day-to-day: adopt a maintained, Laravel-native equivalent instead.

• opcodesio/log-viewer — actively maintained, search, level filters, host-authorization, artisan helper.
• rap2hpoutre/laravel-log-viewer — minimal single-route viewer for quick local/staging triage.
• Laravel Telescope — the right tool for request-level debugging in local/staging.

Treat this bundle as a UX reference, not a dependency. Extract the idea (list files → filter by level → paginate → tail) and use it to inform a config choice in one of the packages above.

Implementation Patterns

If you're forced to support it on a legacy Symfony 2 app:

• Register in AppKernel::registerBundles() and import the routing file under a prefix you control (/admin/logs) rather than relying on the bundle's default path.
• Put the route behind security.firewall / access_control and restrict by role. The bundle predates authorization; it will expose logs to anyone who can reach the URL.
• Configure the log directory explicitly. Symfony 2 uses app/logs; Symfony 3+ uses var/logs. Pointing at the wrong path silently renders an empty listing instead of an error.
• Override the Twig template via app/Resources/ITNLogViewerBundle/... — that template and the log-path config are realistically the only extension points.
• Bind the whole thing to an internal-only network segment, not the public web root.

If you reimplement the pattern in Laravel (the recommended path):

• One route in routes/web.php behind auth and a can:viewLogs Gate/policy. Never web.php unauthenticated.
• A config value (config/log-viewer.php) with a strict array of allowed log paths. Resolve and canonicalize with realpath() and reject anything outside the allowlist before opening.
• Stream, don't slurp. Use SplFileObject::seek / line iterators for a bounded tail (last N lines). file_get_contents on a multi-hundred-MB log will blow memory_limit and take a worker down.
• Escape everything. Wrap output in <pre> and use Blade's {{ }}. Log lines carry attacker-controlled content (User-Agent, URIs, form values) — unescaped rendering is a live stored-XSS vector.
• Read-only by construction: no write, delete, or rename actions on the filesystem.

Workflow integration:

• Enable only in local and staging, gated by an env check (abort_unless(app()->environment(['local','staging']), 404)).
• Pair it with centralized logging (Loki / Sentry / CloudWatch) for actual incident triage across containers and autoscaled fleets — the file-based viewer only works on a single, persistent box.
• Add it to the onboarding runbook as "how to look at logs without SSH," and document the log path and level filter that the team uses in practice.

Gotchas and Tips

• It will not install in Laravel. Don't burn a sprint on composer why-not; confirm the Symfony 2 / PHP 5 constraint and move on. The realistic answer is a maintained Laravel alternative.
• No maintenance since 2015-01-16. No PHP 8 readiness, no security patching, no CVE response. Expect fatal errors from removed functions, dynamic-property deprecations, and Twig/container compilation changes on any modern framework — before you ever see a working page.
• No built-in authorization. Bundles of this vintage typically expose routes with no firewall rule. Anyone who guesses or is given the URL sees production logs. If you inherit a running copy, check access_control immediately — this is the highest-severity finding.
• Path traversal risk. If a log-path parameter isn't canonicalized against an allowlist, it's an arbitrary file read (?file=../../.env). Always realpath() and verify the result is inside the configured directory.
• Stored XSS via log content. Log lines contain user-controlled material. Twig's autoescape usually saves you — verify the template isn't using |raw. In a hand-rolled port, use Blade {{ }} and nothing else.
• Secrets in logs. Application logs routinely contain tokens, PII, and connection strings. A viewer turns them into a searchable, exfiltratable page. Redact before indexing, or restrict exposure to trusted roles only.
• Memory and rotation. Large files OOM the PHP worker; tail-style streaming avoids it. Rotation can truncate a file mid-read, producing partial output — handle ftell/feof edges if you roll your own.
• Log path drift. Symfony 3's move from app/logs to var/logs is the classic silent failure: the page loads, lists nothing, and no error is raised. Verify the configured path against the actual filesystem.
• Decommission plan. Any surviving copy should be a time-boxed, pinned, feature-flagged deployment with a scheduled removal (before the next PHP/framework upgrade), not a dependency you carry into the next major version.