Nova Login Monitor Laravel Package

Getting Started

composer require naif/nova-login-monitor
php artisan vendor:publish --provider="Naif\NovaLoginMonitor\NovaLoginMonitorServiceProvider"

1. Publish the config and open config/nova-login-monitor.php — this is where the Slack webhook URL and the on/off toggle live. Create a Slack incoming webhook for a dedicated #nova-logins channel rather than a general channel.
2. Put the webhook in .env, not in the config file, so it never lands in version control:

   NOVA_LOGIN_MONITOR_WEBHOOK=https://hooks.slack.com/services/XXX/YYY/ZZZ
   

   Check the published config for the exact key name the package reads — that's the first thing to confirm, since the README is thin.
3. Clear config cache (php artisan config:clear) — Nova apps almost always run config:cache in production, and a stale cached webhook is the #1 "it doesn't work" cause.
4. Smoke test: log out of Nova, log back in, watch the Slack channel. If nothing arrives, check storage/logs/laravel.log and re-verify the webhook with a raw curl.

First use case: a solo-dev or small-team admin panel where you want an out-of-band ping whenever anyone authenticates to /nova. It's an alerting tool, not an audit log — treat the Slack channel as a tripwire, not evidence.

Implementation Patterns

Baseline: global Nova-login alert. Install, configure, done. Every successful login to Nova fires a Slack message. This is the entire happy path and covers 90% of what the package does.

Environment-scoped webhooks. Point dev/staging at a #nova-logins-test webhook so production alerts stay signal-rich. Do this via APP_ENV-conditional config or separate .env files per environment rather than toggling the package off entirely — you want to prove the wiring works before it matters.

Pair with a durable audit trail. Slack messages are ephemeral and rate-limited. For anything you'd need in an incident review, also listen to the login event yourself and write to spatie/laravel-activitylog or a login_events table. Use this package for the alert, your own listener for the record:

// app/Providers/EventServiceProvider.php
protected $listen = [
    \Illuminate\Auth\Events\Login::class => [
        \App\Listeners\RecordNovaLogin::class,
    ],
];

Extend the payload. If the package ships a notification class, point the config at your own subclass to add role, IP, user agent, or geo data. If it only supports a fixed message template, keep the package for the ping and add a second, richer Slack notification of your own on the same event — two messages to the same channel is a fine trade for more context.

Alert on failures too. Brute-force attempts against /nova are the real risk. The package almost certainly only watches successful Login events; add your own Illuminate\Auth\Events\Failed listener that pings Slack (or a PagerDuty-style channel) after N failures from one IP. This is where the day-to-day value actually is.

Impersonation and nova.impersonate. Nova lets admins log in as other users. Decide whether those should alert; if the package doesn't filter them, they'll produce noise or, worse, mask a real login. Test it.

Gotchas and Tips

• It only catches the Login event. Remember-me cookie re-auth, Sanctum/API tokens, SSO callbacks that bypass the standard guard, and long-lived sessions that never re-fire won't notify you. Understand this before you promise "we'll know about every admin login."
• Guard filtering. Nova uses its own nova guard. If the package doesn't check $event->guard === 'nova', you'll get a Slack ping for every front-end user login too. Verify by logging into the main app and watching the channel.
• Blocking HTTP call. Small packages like this often call Slack synchronously inside the login request. A slow or hanging Slack endpoint means slow logins — or a 500 on login if the exception isn't swallowed. Check whether the notification implements ShouldQueue; if not, wrap or fork it. This is the single biggest production risk.
• Slack rate limits (~1 msg/sec per webhook). A CI job or load test hammering Nova logins will get messages silently dropped (HTTP 429 with no visible error). Don't use this as a load-test observability tool.
• Webhook is a secret. Anyone with the URL can post to your channel. Rotate it if it ever appears in a config:cache-generated bootstrap/cache/config.php you've shared, a screenshot, or a support ticket.
• Low adoption / single maintainer. 11 stars and 0 dependents means no community backstop. Pin the exact version in composer.json, read the service provider (~50 lines, it's quick) before shipping, and be prepared to fork. If you only need "post to Slack on login," 15 lines in your own listener does the same thing with no dependency — strongly consider that if this is going into anything long-lived.
• No UI, no commands, no retention. There's no Nova card, no login-monitor:test artisan command, and no database. Debug by firing the event manually:

  event(new \Illuminate\Auth\Events\Login('web', $user, false));
  

  If Slack stays quiet, the problem is the webhook or config cache, not the package.
• Slack message formatting. Legacy attachments are deprecated; if the package uses them, messages may render as plain text or get dropped by newer Slack workspaces. Check what actually arrives before relying on the formatting.
• Logout and password changes are out of scope. For a "monitor" that's a real gap — pair it with Logout and PasswordReset listeners if you want meaningful session visibility.