Fin Sentinel Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. Sentinel is a narrow, purpose-built Filament plugin that puts Laravel log reading inside the admin panel. That is a build-vs-buy call a PM can settle quickly: the alternative is a bespoke page (a few days of engineering plus permanent maintenance) versus adopting a small dependency that already handles file listing, base64 path handling, and — as of v1.2.3 — panel-level authorization. Choose the package unless logging needs are unusual (multi-tenant log isolation, remote/aggregated log sources, retention policy enforcement).
• Support and incident-response workflows. Log access inside the panel removes the "SSH into prod and tail the log" step from on-call and support runbooks. This directly affects the support-tiering roadmap: L1 support can triage without shell access, which is a headcount and escalation-latency decision, not just a tooling preference.
• Access-control and compliance posture. v1.2.3 is the decision-relevant item. Before it, sentinel/logs/{file} answered to no permission at all — any signed-in panel user who guessed a filename (laravel.log is enough) could read logs regardless of role. If you are in or approaching SOC 2 / ISO 27001 / HIPAA scope, this was an audit finding: log files routinely contain stack traces with query fragments, session identifiers, emails, and sometimes credentials. The fix converts log viewing into an explicit, grantable permission, which is what an auditor expects to see. Treat "can this package enforce per-role access to log contents?" as a gating question, and note it was only answered in v1.2.3.
• Role/permission provisioning work. The fix is not free: roles that may read logs now need View:LogFileViewer granted alongside View:LogFileList, or affected users get a 403 where the log used to open. That is a per-environment permission-matrix task for whoever owns Filament Shield configuration — plan it as a rollout item, not a footnote.
• Roadmap signal on the vendor. Shipping a real-panel access test suite (tests/PanelTestCase.php, the package's first) after a permission gap suggests the project is tightening its security testing rather than bolting features on. That is a modest positive for a dependency you intend to keep.

When to Consider This Package

Adopt when all of the following hold:

• You run Filament panels and want log inspection where operators already are, rather than a separate tool.
• You use (or are willing to use) Filament Shield, or you can define a page_LogFileViewer Gate ability, or you accept a single plugin-level canAccess() closure. v1.2.3 supports all three, in that precedence order.
• Your access model needs per-role gating of log visibility — this is the version that actually delivers it.
• You are on a current Filament release and comfortable pinning a small, single-maintainer package.
• You can absorb the upgrade step of granting View:LogFileViewer to the right roles at deploy time.

Look elsewhere when:

• You need centralized/aggregated logging (CloudWatch, Datadog, Papertrail, Loki). Sentinel reads local files; it is not an observability platform and should not be pitched as one.
• You need tamper-evident audit trails of who read which log and when. Sentinel gates access but does not appear to log access events; that belongs in your audit layer.
• Multi-tenant isolation of log contents is required — file-system-backed viewers generally assume one trust boundary per panel.
• You cannot take a minor-version upgrade with a permission-model change in the near term. Staying on ≤v1.2.2 means knowingly shipping an endpoint that leaks logs to any authenticated panel user; that should be an explicit, documented risk acceptance, not an oversight.
• You have no Shield and no Gate in place and no intention of adding one — you would fall back to the plugin closure, which is coarser than per-role control.

How to Pitch It (Stakeholders)

To executives: This is a small Filament plugin that lets authorized staff read application logs from inside the admin panel instead of through server access. The release we are evaluating closes a real security hole: previously, any logged-in panel user could open a log file by guessing its name, with no permission check. Logs commonly contain customer data and internal details, so on a compliance roadmap this was a finding waiting to be written up. The fix makes log viewing an explicit permission, which is the behavior auditors and security reviewers expect. Cost is low — a dependency plus a permission grant per role — and the payoff is fewer people needing production shell access and a cleaner access-control story.

To engineering: Upgrade to v1.2.3. Pages\LogFileViewer now carries HasPageShieldSupport and resolves access in this order: Shield's View:LogFileViewer, then a page_LogFileViewer Gate ability if the host defines one, then the plugin's canAccess() closure. No shield:generate re-run is required — Shield already discovers the page from the panel — but every role that currently holds View:LogFileList must also be granted View:LogFileViewer, or those users will start getting 403s on a page that used to open. Sequence the permission grant with the deploy, not after it. The mount() path check is unchanged, so do not read this release as a hardening of path handling — it is an authorization fix only. The new tests/PanelTestCase.php (bound to tests/Feature/Pages) is test-only and establishes the package's first real-panel access tests, using fixture subclasses that override the trait seams so no Shield class loads in the test process. Worth mirroring that pattern in our own Filament page tests.