Weave Code
Laravel Auth Log Laravel Package
label84/laravel-auth-log
Laravel Auth Log adds an audit trail for authentication activity in Laravel apps. It records successful logins, logouts, and failed attempts with useful context, making it easy to review and query auth history through a clean Eloquent model and configurable setup.
Log user authentication actions in Laravel.
Frequently asked questions about Laravel Auth Log
- How do I install and set up label84/laravel-auth-log in a Laravel app?
- Install it with composer require label84/laravel-auth-log. Publish the migration and config, then run php artisan migrate. Package auto-discovery means you do not need to register the service provider manually on modern Laravel. No application code changes are needed to start capturing the default authentication events.
- Which Laravel and PHP versions does laravel-auth-log support?
- Version 1.4.1 is a compatibility-only release whose sole change is Laravel 13 support, with no new features or breaking changes. Laravel 13 raises the PHP floor compared with earlier majors, so confirm your runtime PHP version before adopting. You should also verify that the illuminate/* constraint actually widened rather than the release dropping older Laravel majors.
- What authentication events does this package log?
- The package registers listeners against Laravel's native authentication events, including Login, Logout, Failed, Lockout, and related events. Each record is persisted to a dedicated table through an Eloquent model. A publishable config lets you toggle which of those events are captured. The default event set is recorded without any application code changes.
- Does laravel-auth-log work with Sanctum, Fortify, Breeze, Jetstream and multi-guard setups?
- Yes, it is designed to compose with them because the integration is additive and sits beside your existing auth stack rather than inside it. It does not override container bindings, provide a custom guard driver, or inject middleware into the request pipeline. That makes it low-risk alongside Sanctum, Fortify, Breeze, Jetstream, and multi-guard configurations.
- Why are some logins, such as API tokens or SSO callbacks, missing from the auth log?
- The package works by listening to Laravel's native authentication events, so coverage is by convention. Anything that authenticates without firing a native event, such as custom token issuance, SSO callbacks, or some social login flows, will silently not be logged. You should map each authentication pathway in your application to the events the package listens to. If a pathway does not fire one, it needs separate handling.
- How do I configure which authentication events are recorded?
- Publish the package config file and use its toggles to choose which events are captured. Configuration is the recommended way to control behaviour rather than querying the Eloquent model directly. Keeping your application decoupled from the model makes the package easier to remove later. The config is publishable as part of the standard install steps.
- How do I query the authentication history once it is being logged?
- Records are stored in a dedicated table and exposed through a clean Eloquent model, so you can query auth history like any other Laravel model. The migration is publishable and run with php artisan migrate during setup. For reversibility, prefer the config toggles over direct model queries in application code. That way removing the package leaves no residual coupling.
- Does laravel-auth-log store personal data, and is it GDPR compliant?
- By default the package persists IP address and user agent, both of which are personal data under GDPR and CCPA. That creates a system of record that likely was not previously covered by your privacy notice or retention policy. This is the item most likely to need legal or security sign-off before adoption. Review what you store and how long you keep it before enabling it in production.
- How do I stop the auth log table from growing without limit?
- There is no built-in retention or pruning mechanism, so you need to add one. Steady-state traffic writes roughly one row per auth event, but hostile traffic such as credential stuffing or password spraying generates a row per failed attempt, which is exactly when volume spikes fastest. Plan a scheduled command, partitioning, or an external job to prune or archive the table. Decide your retention requirement before you go live.
- What happens if the log write fails during login, and is this package still maintained?
- Whether a database write failure on the Login listener throws and blocks authentication (fail-closed) or is swallowed (fail-open) is unverified and should be tested in your environment. Fail-closed is unacceptable for a logging concern, so confirm the behaviour before relying on it. On maintenance, this is effectively a single-maintainer project; the prompt Laravel 13 compatibility PR is a positive responsiveness signal, but there is no organizational backstop. The single-commit 1.4.0 to 1.4.1 delta suggests low velocity, so do not assume day-one Laravel 14 support.
Weaver
How can I help you explore Laravel packages today?