- How do I install ichtrojan/laravel-otp in a Laravel application?
- Install it with Composer using composer require ichtrojan/laravel-otp, then publish the package config and migrations before running php artisan migrate. The published config file controls code length and expiry behaviour, so review it before going live. Because OTPs are stored in the database, the migration step is required, not optional.
- How do I configure OTP length and expiry time in laravel-otp?
- Publish the package config file and adjust the length and expiry values there. The package is built around configurable code length and expiry, so you should not need to edit package source to change these. Keep expiry short for login flows, and make sure your UI offers a resend link that respects that window.
- Which Laravel and PHP versions does ichtrojan/laravel-otp v2.0.0 support?
- Version 2.0.0 drops the Facade in favour of container-resolved services, which is idiomatic for Laravel 8 and above. The exact supported Laravel and PHP range is defined in the package composer.json, and you should verify it there and in the README before committing to an upgrade. If you are still on an older major, check whether v1.x continues to receive fixes during your migration window.
- How do I generate and validate an OTP in Laravel with this package?
- Resolve the OTP service from the container, typically through constructor injection, then call its generate and validate methods. Generation writes the code to the database with an expiry, and validation checks the submitted code against the stored record. In v2.0.0 you should inject the contract or service rather than calling a static Facade.
- Why does Otp::generate() fail after upgrading to laravel-otp v2.0.0?
- The Facade was removed in v2.0.0, so any call to Otp::generate() or Otp::validate() will fail until you refactor it. This is a hard breaking change that touches every call site in your application. The fix is mechanical but broad: inject the underlying service or contract, and update tests that mocked the Facade with Otp::shouldReceive() to mock that contract instead.
- What breaking changes should I check before upgrading from laravel-otp v1.x to v2.0.0?
- Three things: Facade removal, alphanumeric token generation, and the refactored validate() method. Confirm whether alphanumeric codes are opt-in via config or a changed default, because an integer storage column cannot hold letters and may need a migration to varchar. Also verify whether validate() changed its signature, return type, or exception-versus-boolean semantics by reading the diff or test suite rather than trusting a changelog line. Run the upgrade on a throwaway branch first and exercise your real verification flow end to end.
- Does ichtrojan/laravel-otp generate numeric or alphanumeric OTP codes?
- Alphanumeric token generation arrives in v2.0.0, so the answer depends on your version and config. Check whether the package exposes this as a config flag or has simply changed the default, since the latter is a silent behavioural change. If you store codes in an integer column, any alphanumeric output requires a schema migration to a string type, and custom regex or is_numeric checks in your validation code must be updated too.
- How do I automatically clean up expired OTPs in Laravel?
- The package ships an artisan command, otp:clean, which removes expired records from storage. Schedule it in your console kernel or scheduler so the table does not grow unbounded. If you monitor scheduled tasks by exit code or stdout, check whether v2.0.0 changed the command output format before relying on it in alerting.
- How do I test or mock laravel-otp in my Laravel test suite?
- Because v2.0.0 removed the Facade, you should bind and mock the underlying contract or service in the container rather than using Otp::shouldReceive(). Constructor injection makes this straightforward in feature and unit tests. If you assert on generated codes, keep the length and expiry config consistent between your test environment and production expectations.
- Is laravel-otp suitable for production, and what should I watch out for?
- It is a lightweight, database-backed OTP service, so its production readiness depends mostly on how you wrap it. Add your own rate limiting and attempt throttling, keep expiry windows short, and ensure the stored codes are not exposed through logs or API responses. If you need hashed storage, multi-channel delivery, or managed provider failover, compare it against a dedicated OTP or verification service before adopting it.