Nova Lock Screen Laravel Package

Getting Started

Because this package has zero stars, no dependents, and no published usage documentation beyond its description, treat the repo as the source of truth. The steps below are the typical flow for a Nova lock-screen tool; verify names against the package's README.md and composer.json before relying on them.

1. Install it

   composer require lahirulhr/nova-lock-screen
   

   Check the composer.json of the package first — Nova tools usually pin laravel/nova and may declare a tight PHP/Laravel range. If Composer resolves to an old build, look at the require block and the last commit date.

2. Register the tool with Nova Lock screens are almost always Nova tools, so add it to app/Providers/NovaServiceProvider.php:

   use Lahirulhr\NovaLockScreen\NovaLockScreen;
   
   public function tools()
   {
       return [
           new NovaLockScreen(),
       ];
   }
   

3. Publish assets/config if offered

   php artisan vendor:publish --provider="Lahirulhr\NovaLockScreen\NovaLockScreenServiceProvider"
   

   Inspect what gets published — a JS/CSS bundle, a config file, or a migration. A lock-screen tool typically publishes a Vue component that hooks into Nova's layout.

4. First use case: lock the panel after N minutes of inactivity, then require the current user to re-enter their password to resume. That is the minimal, sensible thing to prove out — log in, walk away, come back, confirm you get the overlay and that a valid password unlocks it.

Where to look first, in order: the package's README.md, its src/ service provider (for config keys and Nova hooks), resources/js/ (to see how the lock state is persisted — cookie, localStorage, or session), and its migrations if any.

Implementation Patterns

• Global lock behavior. Most of these tools mount a single Vue component into Nova's layout and poll for activity. There is usually no per-resource configuration — it applies to the whole panel. If you need role-scoped locking (e.g. only non-admins), you will likely have to fork the component or wrap registration in a conditional inside NovaServiceProvider::tools().
• Timeout configuration. Expect a config/nova-lock-screen.php or an env-driven value (often NOVA_LOCK_TIMEOUT). Standardize it with a matching Laravel session lifetime so the Nova lock fires before the session expires — otherwise users see the lock screen, type their password, and get bounced to login anyway.
• Re-authentication flow. The unlock step should validate against the currently authenticated guard rather than a hardcoded user model. In multi-guard Nova setups (config/nova.php → guards), confirm the package reads Auth::guard(config('nova.guard')) — if it hardcodes Auth::user(), wrap or patch it.
• Pair with session security. Combine with SESSION_LIFETIME and Nova's idle timeout so you get defense in depth: server-side session expiry plus a client-side lock overlay for convenience and shoulder-surfing protection.
• Inertia/Livewire coexistence. If your Nova is customized with custom tools or dashboards, test that the lock overlay still renders above modals and resource drawers. A z-index conflict is the single most common integration issue with overlay tools.
• CI coverage. Since you cannot rely on the package's own test suite, add a smoke test in your app: assert the lock route/endpoint exists and rejects a wrong password, and that a valid password unlocks. This makes future package upgrades (or a replacement) safe.

Gotchas and Tips

• No maintenance signal. Zero stars, zero dependents, and a zero score mean no community eyeballs. Pin the exact version in composer.json, vendor-lock it, and plan an exit: the lock screen is a small enough surface that forking a single Vue component is a realistic fallback if the package breaks on a Nova upgrade.
• Nova major-version drift. Nova ships breaking changes to its layout and mix build across majors (v4 → v5 in particular). Check the package's package.json against your Nova version; a mismatch usually manifests as a blank panel or a missing overlay, not a clean error.
• SPA state. Nova is a Vue SPA, so a lock overlay that relies on a full page reload to clear will behave oddly on navigation. Confirm the unlock triggers a reactive state change, not a window.location.reload().
• Client-side is not security. A JS lock screen is a UX deterrent, not an auth boundary. Anyone with the session cookie can bypass it. Do not treat it as a substitute for auth middleware or session expiry on sensitive routes; combine it with server-side policies.
• Debugging. If the overlay never appears, check: (1) the tool is actually registered in tools(), (2) php artisan nova:publish ran after install, (3) the compiled JS is served from public/vendor/… and not stale cache (npm run dev in the Nova app if you have a custom nova-components build), and (4) browser console for a Vue mount error — that will tell you if it is a version mismatch.
• Config cache. After changing any published config, run php artisan config:clear; a cached config with the old timeout is the most frequent "it doesn't lock" report.
• Extension points to inspect. The service provider (usually NovaLockScreenServiceProvider) and the main tool class are where you would add a canSee/canRun guard, swap the timeout source, or override the Vue component via Nova::script(). If the package exposes none of these, that is the argument for a fork rather than a PR.