Nova Secret Field Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel Nova custom field — it registers a Field subclass and ships a compiled Vue component that renders a masked value with a reveal toggle. That is a well-understood, low-surface extension point in Nova, so conceptually it slots into any Nova-based admin panel without touching application domain code. The catch is that Nova is a paid, closed-source first-party product with infrequent but breaking major releases (v3 → v4 changed the frontend stack to Vue 3/Inertia/Vite; v5 landed in 2024). Any Nova field package is therefore version-locked to a Nova major, and this one was last released in July 2022 and is now archived — it targets Nova 3.x (at best early 4.x) and will not build against a current Nova install.

Integration feasibility. Low for anything on a modern stack. Installation is a standard composer require plus Nova's field registration, but the practical blockers are: (1) the Vue asset bundle predates Nova's Vite/nova.mix.js tooling, so a Nova 4.24+/5 host will fail at asset compilation or fail silently at render; (2) composer constraints on laravel/nova are almost certainly pinned to an old major, forcing a dependency conflict; (3) zero dependents and three stars means no field validation from other teams — no evidence anyone runs this in production today.

Technical risk. The dominant risk is not abandonment, it's the security model being cosmetic. A "toggle to reveal" is a client-side affordance: unless the field actively redacts on resolve(), the plaintext secret is serialized into the Nova resource JSON response and delivered to every browser that loads the index or detail view. Anyone with Nova view permission — or anyone with a devtools network tab, a browser extension, or a proxy log — reads the value without ever clicking the toggle. Secondary risks: the value is stored in whatever column the developer points at, and there is no indication the package enforces encryption at rest; Nova's global search, index columns, filters, and CSV/export actions can each leak the field independently of the toggle; and an archived repo means no CVE intake, no security patches, and no one to ask.

Key questions.

• Which Nova major(s) does the composer.json constraint actually allow, and what does the Vue build target?
• Does the field redact the value server-side for index/lens/search payloads, or only visually in the detail view?
• Is the underlying column expected to use Laravel's encrypted cast, or does the package assume plaintext storage?
• Does it respect Nova authorization (canSee/canUpdate/policies), or is visibility governed only by the toggle?
• Is the reveal action audited anywhere (log, event, Nova action log)?
• MIT license confirmed — is forking and re-releasing internally acceptable to legal?

Integration Approach

Stack fit. Only viable on Laravel 9/10 + Nova 3.x. On Nova 4.24+/5 the package is not a drop-in; treat it as reference source, not a dependency. The PHP side is trivial (one field class); the Vue side is the part that needs rebuilding.

Migration path. Three options, in order of preference:

1. Build a thin in-house Nova field. The functional surface is small: a masked display, a reveal control, and a policy gate. Pair an encrypted cast on the model with a field that returns a redacted placeholder by default and exposes plaintext only through a dedicated, authorization-checked, audit-logged reveal endpoint. This keeps plaintext out of the resource payload entirely and is a few hundred lines of owned code.
2. Fork and vendor. MIT permits it. Copy the package into the app or an internal Composer path repository, rebuild the Vue component against the current Nova tooling, and add server-side redaction that the original lacks. Only worth it if the UI/UX of the existing field is genuinely valued.
3. Adopt as-is. Not recommended at this maturity level.

Compatibility. PHP 8.x is fine; the hard constraint is the Nova major and its frontend build chain. Any fork inherits an obligation to re-verify on every Nova upgrade.

Sequencing.

1. Inventory every place a secret could surface: resource index and detail, lenses, filters, global search, action modals, exports, and Nova's own request/response logging.
2. Write down the threat model and the policy — who may see plaintext, under what conditions, and what gets logged. Get security/compliance sign-off before code.
3. Prototype the in-house field behind a feature flag on a single low-risk resource.
4. Security review: capture the actual network payload and confirm the secret is absent unless explicitly revealed; confirm encryption at rest; confirm audit entries.
5. Roll out per resource, then remove the third-party package and its transitive constraints from composer.json.

Operational Impact

Maintenance. Archived means your team owns it outright — there is no upstream to patch, no issue triage, no release cadence to ride. The code footprint is small, but Nova majors arrive roughly every 18–24 months and each one will require touching the Vue build. Budget it as an internal component with a named owner, not as a dependency.

Support. No vendor, no SLA, no security disclosure channel. If a vulnerability is found in the reveal path, the fix is entirely yours to write and ship. That is acceptable for a trivial UI widget and unacceptable for anything touching credentials unless you have already taken ownership of the code.

Scaling. Runtime cost is negligible — a field render on an admin page. The dimensions that actually scale are the number of secret-bearing resources and the audit/compliance surface. More secrets means more places to verify redaction, more policies to keep coherent, and more log volume once reveal events are audited.

Failure modes.

• Silent asset/compile breakage on a Nova upgrade; the field stops rendering and someone "fixes" it by loosening the constraint.
• Plaintext leakage through the resource JSON payload, Nova global search indexing, filter values, exports, or application logs — the highest-severity failure and the one most likely to go unnoticed because the UI still looks masked.
• Unencrypted column, so DB dumps and backups become a secret-disclosure event.
• Authorization drift: a policy change grants a role view access, and the toggle is treated as the control when it never was.
• Orphaning — the maintainer's account or repo disappears and the source of truth for the built assets is gone.

Ramp-up. Technically shallow: a mid-level Laravel engineer can read the whole package in an afternoon. The real ramp is educational — anyone who touches or reviews this field must internalize that masking is a UX affordance, not an access control, and that the reveal toggle provides zero protection against a determined viewer. That framing needs to be in the PR description, the runbook, and the security review, or the field will be cited as a control it does not provide.

Recommendation. Do not adopt as a dependency at its current state — the 0.10 score is consistent with what the repo shows: archived, single-maintainer, no downstream validation, and a security posture that is presentational rather than enforced. Build the equivalent in-house with server-side redaction and encryption, or fork under MIT and own it explicitly.