Fb Passwd Laravel Package

Getting Started

• Install with composer require mortezamasumi/fb-passwd. Version 5.2.0 is the first release with a Laravel 13 constraint — confirm your composer.json php requirement satisfies whatever the package's illuminate/support constraint pulls in (Laravel 13 raises the floor again, so a legacy PHP 8.2 app will silently stay on 5.1.x).
• First place to look after install: vendor/mortezamasumi/fb-passwd/composer.json for the exact supported framework matrix, then the package's src/ service provider to see what is auto-registered (rule alias, facade, config, translations).
• Publish anything shippable before writing code: php artisan vendor:publish --provider="Mortezamasumi\FbPasswd\FbPasswdServiceProvider" and diff the config into version control. Config is the contract — treat unknown keys as "don't touch until read".
• Verify discovery took effect with php artisan about or by grepping bootstrap/cache/packages.php for the provider name. If it isn't listed, you are running a stale cached manifest, not a broken package.
• First real use case: a StorePasswordRequest / ResetPasswordRequest FormRequest that layers the package's rule on top of Laravel's built-in Password::defaults() chain. This is the one place a compromised-password check earns its keep, and it is where you will iterate on messaging.

Implementation Patterns

• FormRequest-first. Keep the rule out of controllers. A Rules\Password chain plus the package rule reads cleanly:

  public function rules(): array
  {
      return [
          'password' => [
              'required', 'string', 'confirmed',
              Password::defaults(),
              new FbPasswd(),
          ],
      ];
  }
  

• String alias vs. rule object. If the package registers a validator extension (e.g. 'password' => 'fb_passwd'), prefer the object form in new code — it survives refactors, gives you constructor arguments for thresholds/options, and is trivially mockable in tests.

• Centralise in a preset. Do not repeat the chain across registration, reset, and password-change. Wrap it in a PasswordRules::default() helper (or extend Password::defaults()) so the Laravel 13 upgrade and future rule changes touch one file.

• Decorate, don't replace. Laravel's Password::defaults() already handles length, mixed case, and uncompromised() (HIBP). If fb-passwd overlaps with uncompromised(), pick one as the source of truth — running two breach checks on every registration is pure latency.

• Cache remote lookups. If the rule performs HTTP or a DB read, wrap it in Cache::remember() keyed by a hash of the password (never the plaintext) with a now()->addDay() TTL. Registration traffic is bursty and the same weak passwords recur constantly.

• Fake it in tests. Use Http::fake() if the check is API-backed, or bind a stub implementation of the rule's contract in the container for feature tests. Keep one integration test that hits the real path, marked in a separate suite, so CI does not depend on an external service.

• CI matrix. With 5.2.0 you can now test laravel/framework: ^11 | ^12 | ^13 in one workflow. Add Laravel 13 to the matrix explicitly; don't rely on --prefer-lowest to catch constraint drift.

Gotchas and Tips

• The Laravel 13 bump may be a constraint narrowing, not just a widening. Read the diff on composer.json in bd37f92. If illuminate/support went from ^11.0|^12.0 to ^13.0, upgrading on a Laravel 12 app will resolve backwards to 5.1.4 without error — pin "mortezamasumi/fb-passwd": "^5.1" if you need to stay put, and confirm what you actually have with composer show mortezamasumi/fb-passwd.
• Auto-discovery silently disabled in apps with dont-discover entries — the rule alias then throws "method does not exist" rather than a package error. Check composer.json extra.laravel.dont-discover before blaming the package.
• Do not leak the reason. Return a single generic message for any failure ("This password is not acceptable"). A per-rule message that says "found in a breach corpus" tells an attacker which inputs are known-good for spraying.
• Message and translation registration. Publish the package's lang/ files if present and override under lang/vendor/fb-passwd/; otherwise you will ship English strings into a localised app and only notice in staging.
• Cost of the rule on every request. Validation runs on all requests that use the FormRequest, including API endpoints and artisan-driven commands. If the check is IO-bound, make the rule opt-in per form rather than baking it into a base request class.
• Extension point: if the rule is a Rule object, subclass it and override message() / passes() for custom policy (e.g. allowlisted legacy passwords, staff exemptions). That is safer than forking the package for a one-line difference.
• Debugging failures: temporarily dd() inside a small custom rule wrapping the package rule to see whether passes() is returning false or an exception is being swallowed by the validator. Validation exceptions are converted to messages and disappear from logs unless you are watching storage/logs/laravel.log at the right level.
• Version pin sanity after upgrade: run composer why-not mortezamasumi/fb-passwd 5.2.0 — it prints the exact conflicting package and constraint. This is the fastest way to resolve "Laravel 13 supported" not becoming "installed".