- How do I install jrean/laravel-user-verification in a Laravel application?
- Install it with Composer using composer require jrean/laravel-user-verification, then publish the package config and migration files with the vendor:publish command. Run the migration to add the verification columns to your users table, add the package trait to your User model, and optionally point the package at your own notification view. Because it modifies the users table, test the migration against a copy of production data before rolling it out.
- Which Laravel and PHP versions does jrean/laravel-user-verification support?
- The package is built for conventional session-based Laravel applications and is aimed at the Laravel 5.x through 8.x era, where native email verification either did not exist or was still settling in. The README's version table is not a substitute for testing: pin an exact release and run it through your own CI matrix against your target Laravel and PHP versions before committing. If you are targeting Laravel 10, 11, or 12 with PHP 8.2+, verify compatibility explicitly rather than assuming it.
- Is jrean/laravel-user-verification still needed now that Laravel has built-in email verification?
- For Laravel 5.7 and later, the framework already ships MustVerifyEmail, the verified middleware, signed verification URLs, and the VerifyEmail notification, which covers the same core use case with zero third-party dependency. For a modern or greenfield application, the native feature is almost always the better choice because it upgrades with the framework and carries no license or maintenance risk. This package is mainly a credible shortcut for legacy apps that have no verification flow at all or a half-finished custom one.
- Does jrean/laravel-user-verification replace MustVerifyEmail or can it coexist with it?
- Both approaches add a verified flag and a trait to the User model, so running them side by side risks trait and method collisions. If you need to support both, isolate this package behind your own interface or a legacy-only code path so the two verification flows never touch the same model methods. Confirm in code which trait methods and columns each one uses before enabling both in a single application.
- Are the verification tokens single-use, expiring, and rate-limited on resend?
- Token lifecycle is the highest-risk part of any email verification package, and you should read it in the source rather than trust the README. Specifically check that tokens are invalidated after a successful verification, that they carry a signed expiry, and that the resend endpoint is throttled to prevent mail-bombing and enumeration. If any of those behaviors is missing, add throttling middleware and your own expiry check before shipping.
- How do I protect routes so only verified users can reach them?
- The package provides middleware that blocks unverified accounts and redirects them back to the verification prompt, following the standard Laravel middleware pattern. Register it in your HTTP kernel or bootstrap file and attach it to the route groups that require a confirmed email address. Test the redirect path and the already-verified case explicitly, since middleware ordering with your auth guard is a common source of redirect loops.
- Can I customize or localize the verification email sent by jrean/laravel-user-verification?
- Yes, the notification view is publishable, so you can rebrand, restyle, and translate the message without forking the package. Publish the views and override the copy in your own resources/views directory, then confirm the change renders correctly through your actual mail transport. If you support multiple locales, test that the email uses the recipient's locale rather than the request locale, which is a frequent bug in queued notifications.
- Does jrean/laravel-user-verification work with an API-only or SPA backend using Sanctum or JWT?
- Not well. The package assumes a session guard and a redirect-based verification UX, which does not map cleanly onto stateless token authentication or headless frontends. For API-first or SPA architectures, implement verification yourself with Laravel's signed temporary URLs and a frontend route, or use the native MustVerifyEmail flow with a custom notification. The same limitation applies if identity is delegated to SSO or OIDC.
- What happens if my users table already has a verified column or an existing custom verification flow?
- The published migration can collide with an existing verified column or change its semantics, such as nullable versus default false, so review it before running it in production. Make the migration idempotent and confirm it does not silently rewrite existing rows that your current flow depends on. If you already have a working custom flow, adopting the package means reconciling two sources of truth for verification state, which is rarely worth it.
- Is jrean/laravel-user-verification actively maintained, and what license does it ship under?
- It follows the single-maintainer pattern common to this package class, so check the last commit date, issue-triage cadence, and Packagist release history yourself before adopting it. The package metadata reports NOASSERTION, which means automated license scanning cannot classify it, so legal sign-off is required before shipping it in a distributed product or a regulated environment. Pin an exact version and have a plan to swap to Laravel's native verification if the package stalls.