- What is finity-labs/fin-sentinel used for?
- Fin Sentinel is a Laravel package that plugs into an existing Filament admin panel to add application monitoring conveniences. It registers two panel pages — a log file list at sentinel/logs and a log file viewer at sentinel/logs/{base64 file} — and also provides error email notifications and a developer debug mail channel. It is aimed at teams that already run a Filament panel and want in-panel log access without building or buying a log UI. It is not a log aggregation or full observability platform.
- How do I install Fin Sentinel in a Laravel Filament panel?
- Install it with Composer, then register the plugin in your panel provider so its two pages appear in the admin panel. You can optionally publish the package config if you need to change defaults. There are no database migrations or external services to stand up. The main remaining work after installation is authorization: making sure only the right roles can reach the log pages.
- Which Filament versions does Fin Sentinel support?
- Fin Sentinel is built as a Filament panel plugin and is intended for Filament v3 and v4 panels running on Laravel. Because it depends on panel registration and page-level authorization, confirm the exact version constraints in the package's composer.json before upgrading an existing panel. If you use Filament Shield, the plugin's pages participate in Shield's permission discovery.
- Is Fin Sentinel affected by a security issue in v1.2.2 and earlier?
- Yes. Before v1.2.3, the LogFileViewer page implemented neither HasPageShieldSupport nor its own canAccess(), so any authenticated panel user could open log files by guessing a filename — laravel.log was enough — regardless of role. Laravel logs commonly contain stack traces, query fragments, connection strings, email addresses, session identifiers, and occasionally tokens or PII. If you are on v1.2.2 or earlier, treat this as an active exposure, upgrade to v1.2.3, and assess how broad your panel access really is.
- Why do users get a 403 on the log viewer after upgrading to v1.2.3?
- The v1.2.3 release is an authorization fix, so roles that could previously read log files now get a 403 until the View:LogFileViewer permission is granted. Grant it to every role that already holds View:LogFileList and is expected to read logs. You do not need to re-run shield:generate for the page itself. Verify the resulting 200/403 matrix in staging with a real low-privilege role rather than inferring it from the diff.
- Do I need Filament Shield to use Fin Sentinel?
- Shield is optional but it is the primary integration path; Shield already generates the View:LogFileViewer permission from panel discovery. The authorization fallback chain is Shield, then the page_LogFileViewer Gate ability, then the plugin's own canAccess() closure. On a Shield-less install the effective policy is whatever that closure returns, so review it explicitly or define the Gate ability instead of assuming a safe default.
- Does Fin Sentinel require database migrations or external infrastructure?
- No. The package is a thin, self-contained Filament plugin with no database migrations and no external service, daemon, or storage layer. It reads log files from the host's filesystem and renders them inside the panel. That keeps the footprint small, but it also means it is only as useful as the log files actually present on the machine serving the panel.
- How should I test Fin Sentinel's log page permissions before production?
- Upgrade in staging first, then sign in as a low-privilege panel user and confirm both the list page and the viewer return 403. Repeat as an authorized role that holds View:LogFileList and View:LogFileViewer and confirm both return 200. Test with a real non-admin role rather than an admin account, since admins can mask missing grants. Also check the mount() path handling, because directory-traversal protection rests on that single control.
- Does Fin Sentinel work with Docker or ephemeral container filesystems?
- Fin Sentinel reads log files from the filesystem of the host serving the Filament panel, so behavior depends entirely on where your logs live. On ephemeral container filesystems, logs may be lost on restart or split across replicas, so the viewer can show incomplete or stale data. If you run multiple replicas or a shared volume, confirm which log files the panel actually sees before relying on it during an incident.
- Is the v1.2.3 upgrade a routine patch or should it go through change control?
- Semver labels it a patch, but operationally treat it as a permission-breaking change because roles lose log access until View:LogFileViewer is granted. Route it through your normal access-control process rather than a routine dependency bump. There are no schema, config, or public API changes, so the build risk is low — the cost sits in the RBAC rollout and communicating the new 403 behavior to users.