- How do I install and use jord-jd/laravel-password-exposed-validation-rule?
- Install it with composer require jord-jd/laravel-password-exposed-validation-rule, then add the rule class to the rules array for the relevant field in a FormRequest or a Validator::make call. There are no migrations, queue workers, or required service provider steps beyond an optional published config file. The usual placement is the password field on registration and password reset forms.
- Which PHP and Laravel versions does this package support?
- The 6.1 release declares support from PHP 7.4 through 8.5 and Laravel 8 through 13, which covers a wide mix of legacy and current applications. That breadth requires runtime branching and a large CI matrix, so confirm your exact version pair is actually exercised in CI rather than only declared. For the newest majors, such as Laravel 13 and PHP 8.5, early adopters are effectively the first real-world testers.
- Does this rule send plaintext passwords to Have I Been Pwned?
- No. The rule queries the Have I Been Pwned range API, which uses k-anonymity so only a short SHA-1 prefix is sent rather than the full password. That keeps plaintext credentials off the wire, but each validation still performs a synchronous outbound HTTP request. Expect added latency on the request path and plan for upstream rate limits.
- Can I use this rule alongside Laravel's Password::min()->uncompromised()?
- It composes with Laravel's Password rule chain, including Password::min()->uncompromised(), because both operate at the validator layer. Running both is redundant since they check the same breach corpus, so pick one and keep rule ordering consistent with the rest of your chain. Check the package's composition documentation for the recommended ordering before you rely on it.
- What happens if the Have I Been Pwned API is down or slow during validation?
- Because the lookup is synchronous and depends on a third-party service, timeouts, retries, caching, and a fail-open versus fail-closed policy are the first things to configure. Check whether the optional published config exposes those knobs, and decide deliberately whether a breach-check outage should block sign-ups or let them through. For air-gapped or egress-restricted environments you would need an offline dataset or custom resolver, so verify that option exists before adopting.
- Why does the rule behave differently for null, integers, arrays, or booleans after upgrading to 6.1?
- In 6.1, non-string values such as integers, arrays, null, and booleans are no longer coerced for the lookup; they defer to Laravel's own string and type rules instead of raising a conversion warning. Objects with __toString, including value objects and UUID or email wrappers, are still evaluated as strings. This is a correctness fix, but it can change whether a loosely typed JSON payload passes, so add tests for those cases before rolling forward.
- How do I test a form request that uses this validation rule?
- Use Http::fake or an equivalent mock so your tests never hit the real Have I Been Pwned API. Assert the rule's behavior for a known-breached string, a clean string, null, an integer, an array, a boolean, and a Stringable value. That matrix catches both the network dependency and the 6.1 non-string behavior change.
- Is this package suitable for production, and what about rate limits and performance?
- It is a small leaf dependency, so the package itself is low risk, but the outbound breach lookup becomes part of your service's availability surface. Set a short timeout, add caching where the same password may be validated repeatedly, and watch for rate limiting at volume. Treat upstream failures as a product decision rather than an implementation detail.
- How does this compare to Laravel's built-in uncompromised password rule?
- Laravel ships Password::uncompromised() from 10.10 onward, which uses the same Have I Been Pwned range API. This package is most useful when you need a standalone rule object, support for older Laravel versions, or configurable lookup behavior across a mixed-version estate. If you are on a current Laravel release and only need the default behavior, the built-in rule may be enough.
- Who maintains this package, and is there a support or security policy?
- The package appears to be maintained by a single author, so bus factor, release cadence, and the security disclosure channel are worth checking before standardizing on it. Look for a published support or LTS policy, and confirm that the declared PHP 7.4 floor is a real commitment rather than an untested lower bound. Pinning the version and reviewing release notes on each bump is prudent.