Weave Code
Verify By Phone Laravel Package
worksome/verify-by-phone
Verify phone numbers in Laravel with one-time codes delivered by SMS or automated phone call. This package offers configurable drivers, rate limiting, and simple model integration, so you can add secure phone verification to registration, login, or profile flows in minutes.
A package for verifying a user via call or SMS
Frequently asked questions about Verify By Phone
- How do I install worksome/verify-by-phone in a Laravel app?
- Install it with composer require worksome/verify-by-phone, then publish the package config and migrations using the standard vendor:publish command. Next configure an SMS driver and its credentials, and add the package trait or contract to your Eloquent user model. Auto-discovery registers the service provider, so no manual provider registration is needed.
- Which Laravel and PHP versions does this package support?
- The current release, v0.6.1, adds Laravel 13.x compatibility alongside earlier framework versions, and the stack fit spans Laravel 10 through 13 on PHP 8.1 and above. Always confirm the exact constraints in the published composer.json before planning a framework upgrade, since transitive dependencies can lag behind. Because the package is pre-1.0, check the changelog on each bump.
- Which SMS providers and drivers are supported?
- The package is built around a driver-based SMS abstraction with a facade and contract surface, so providers can be swapped through configuration. The exact set of in-tree drivers is not guaranteed to cover every region or carrier, so verify that your target provider is supported before treating the driver layer as a differentiator. No external service account is required beyond your chosen SMS provider.
- Are verification codes hashed at rest or stored in plaintext?
- Code storage is a security surface you must review rather than assume, along with code entropy, TTL, max attempts, and resend cooldown defaults. Check the migration and verification model to see whether codes are hashed or persisted in plaintext before going to production. If they are stored in plaintext, consider tightening entropy and shortening TTL to reduce exposure.
- How do I test phone verification in CI without sending real SMS messages?
- The driver-based architecture and mockable facade and contract make it possible to swap in a fake or null driver during automated tests. Spike the request, verify, and middleware flow end to end in a feature branch with that fake driver before wiring a real provider. This keeps your test suite fast, deterministic, and free of SMS costs.
- What are the defaults for code TTL, attempts, and resend cooldown?
- The package owns the full OTP lifecycle including issue, store, verify, and throttle, and those values are intended to be configurable through the published config file. Review the config after publishing to confirm the TTL, maximum attempts, and resend cooldown defaults are appropriate for your risk tolerance. Document the chosen values so future maintainers do not weaken them accidentally.
- Does the package normalize phone numbers to E.164 format?
- Number normalization and validation to E.164 may be your responsibility rather than the package's, so confirm the behavior before relying on it. The safest integration path is to backfill and normalize existing numbers to E.164 and add a nullable phone column with a unique index where appropriate. Doing this first prevents duplicate accounts and mismatched identifiers during verification.
- How does this help prevent SMS toll fraud and pumping attacks?
- Toll fraud is the highest-severity operational risk with any OTP system, and the package provides rate limiting that must be validated under load. Test limits per identifier and per IP, not just globally, and monitor send volume for anomalies. Combine the built-in throttling with provider-side spending caps and alerts for defense in depth.
- Can I use worksome/verify-by-phone if I am not using Laravel's default auth stack?
- It fits best with apps already on Laravel's auth stack and an Eloquent authenticatable model that has a phone attribute. If you use a separate identity service or a non-Eloquent user store, you would need an adapter layer around the package contracts. The package replaces homegrown verification code rather than layering on top of an existing OTP system.
- Is this package safe for production given its pre-1.0 version number?
- At 0.x, minor releases may include breaking changes, so pin to a specific version such as ~0.6.1 and read the changelog on every bump instead of floating the constraint. Positive signals include prompt Laravel 13 support and active dependency maintenance, but there is no commercial SLA and maintainer concentration is a consideration. Keep SMS credentials in a secrets manager, verify logging redacts phone numbers, and confirm a 1.0 release and backward-compatibility policy are on the roadmap.
Weaver
How can I help you explore Laravel packages today?