- How do I install and configure nextapps/laravel-verification-code in a Laravel app?
- Install it with Composer, publish the package config and migration, run php artisan migrate, and add the HasVerificationCodes trait to your User model. You then create and send a code through the VerificationCode facade and verify submitted input with the companion verify call. This is a small integration, typically an hour for a spike and a few days for a hardened flow.
- Does this package support Laravel 10, 11, or 12 and PHP 8.x?
- The package is aimed at Laravel applications on PHP 8.x, but the provided context does not list a definitive tested Laravel and PHP support matrix. Check the composer.json constraints and Packagist release metadata for your current and next LTS before committing. The technical assessment specifically flags confirming the tested support matrix as an open question.
- Can I use it for passwordless login or two-factor authentication?
- It is an OTP primitive for creating, sending, and verifying one-time codes, not a complete passwordless login or two-factor authentication product. You can use it as a building block for login, signup, and password reset verification, but routes, controllers, request validation, sessions or guards, lockout behavior, and audit logging remain your responsibility. For step-up auth or flows guarding money or PII, review the storage and attempt-limit risks first.
- Are verification codes hashed at rest in the database?
- The technical evaluation found no evidence that codes are hashed at rest; they appear to be persisted as plaintext in the verification_codes table and compared directly. That may be acceptable for low-value email verification but is questionable for step-up authentication or anything protecting money or PII. Review the schema and code path, and add hashing or a compensating control if your threat model or compliance scope requires it.
- Does it include attempt limits and rate limiting for verification codes?
- The blurb mentions built-in expiry, attempt limits, and rate limiting, but the technical assessment says the package provides expiry and code-length settings rather than per-identifier attempt counters or lockouts. Treat that as something to verify in the current release. In production, layer Laravel's RateLimiter and a per-user attempt counter yourself, and decide whether exhaustion invalidates the code or triggers a cooldown.
- How do I send verification codes via SMS instead of email?
- The default notification channel is mail, so SMS requires overriding or replacing the notification class or wiring a custom channel. That delivery seam is one of the most likely places to break on package upgrades. If SMS is a requirement, wrap delivery behind your own service or notification abstraction and test it against your supported Laravel versions.
- How should I clean up expired verification code rows?
- The package ships a publishable migration for a verification_codes table, but the assessment questions whether a maintenance or scheduled prune command exists. If your release does not provide one, add a first-party scheduled command to delete expired rows. Keep that cleanup in your deployment runbook so the table does not grow indefinitely.
- Is nextapps/laravel-verification-code production-ready and actively maintained?
- The project has roughly 58 stars, effectively zero dependents, and a single-maintainer fork lineage, so there is limited production-validation signal. The listed last release date is anomalous and should be checked against Packagist before treating it as actively maintained. Budget for first-party hardening and review maintainer responsiveness and release cadence over the last 12 months.
- Should I call the VerificationCode facade directly or wrap it in a service?
- Calling the VerificationCode facade directly from controllers is the fastest route, but it couples your codebase to the package. Wrapping it behind an internal VerificationService interface takes a little more time and makes the package swappable, easier to test, and simpler to replace if delivery or security needs change. For a hardened implementation, the wrapper is usually worth it.
- What security controls must I add around OTP verification in production?
- You must add strict per-user and per-IP attempt limits, rate limiting, lockout or cooldown behavior, user-enumeration defenses, audit logging, and reliable cleanup of expired codes. Also consider queueing notifications so OTP sends do not block request threads, and verify whether code hashing at rest is required for your compliance scope. The package is a narrow building block; these production controls sit outside its boundary.