Laravel User Activity Log Laravel Package

Getting Started

This package sits on top of Laravel's authentication event system to record who logged in, who logged out, and from where. The v1.4.2 patch is a maintenance release, but it is a meaningful one for anyone running more than one authenticatable model, so treat it as the baseline version to install.

1. composer require the package, then publish its config and migrations (php artisan vendor:publish --tag=...) and run php artisan migrate. Check that the migration lands a table with a polymorphic authenticatable relation plus IP, user agent, and timestamp columns.
2. Open config/authentication-log.php (or equivalent) first — table name, enabled event types, and the model/guard mapping all live there. This file tells you more about how the package behaves than the README does.
3. Attach the package trait (and/or interface) to every model that can authenticate, not just App\Models\User.
4. First use case: confirm a successful login creates a row. Log in through your normal flow, then Model::latest()->first() on the log table. If nothing appears, the event listener is not registered for that guard.

The most common first use case is an "active sessions / recent logins" panel on a user's account page, followed by an admin-facing audit trail.

Implementation Patterns

Multi-guard applications. The headline fix in v1.4.2 is logging across multiple authenticable models. The pattern that works is to put the trait on each model (User, Admin, Customer) and let the package resolve the subject through the polymorphic relation rather than assuming App\Models\User. If you maintain a custom config/auth.php with several providers, verify each provider's model is instrumented — a guard whose model lacks the trait will silently produce no log entries.

Querying logs. Use the morph relation for per-user activity ($user->authentications) and add your own scopes for reporting: date ranges, IP grouping, failure counts. Because the relation is polymorphic, dashboards that span admins and users need with('authenticatable') and a morphMap if you use custom morph aliases.

Failed attempts. Failed logins are only useful alongside a rate-limit or alerting consumer. A weekly scheduled command that groups failures by IP and emails above a threshold is a small, high-value addition. Pair it with Laravel's RateLimiter so the log is evidence rather than the control.

Retention. These tables grow quickly. Schedule a prune command (->where('login_at', '<', now()->subMonths(6))->delete()) or chunked deletes; do not leave it unbounded on a busy app.

Integration tips. If you already listen to Illuminate\Auth\Events\Login, register your own listener alongside the package's rather than replacing it. For queued or API-driven auth (Sanctum tokens), remember that these are not session logins — decide consciously whether token issuance should be logged via a custom event.

Gotchas and Tips

• Upgrade if you are multi-model. Prior to v1.4.2, logging was broken for setups with multiple authenticable models, and the log event fired even when no user was logged in. If you saw rows with a null subject or logs attributed to the wrong model, that is the bug — upgrade and consider cleaning up the junk rows.
• Guest rows. The second fix means you should no longer see entries created for unauthenticated requests. If you still do after upgrading, you have your own listener calling the logger unconditionally.
• .gitattributes excluding tests only affects composer require installs using --prefer-dist. Don't rely on the package's own test suite being present under vendor/; write your own feature test asserting a login creates exactly one row for the correct model.
• IP correctness. Behind a load balancer you will log the proxy IP unless TrustProxies is configured. Verify with a request through your real ingress before trusting the data for security decisions.
• User agent truncation. Long or malformed UA strings can exceed column limits; check the migration and consider trimming at the write path rather than hitting an exception in production.
• Synchronous writes. Logging happens inline with the auth request. On high-traffic login endpoints, measure before adding indexes; a composite index on (authenticatable_type, authenticatable_id, login_at) covers most dashboard queries.
• Extension points. Custom event listeners, a config-driven model override, and the morph relation are the three levers for adapting this package. Avoid editing published migrations; add follow-up migrations instead so future upgrades stay clean.
• Logging the logger. Debugging missing entries is almost always one of: listener not registered for the guard, trait missing on the model, or config event type disabled. Check those three before reading package source.