- How do I install infinitypaul/laravel-password-history-validation?
- Install it with composer require infinitypaul/laravel-password-history-validation. Laravel package auto-discovery registers the service provider, so you normally do not need to add anything to config/app.php. After installing, run the migration so the password history table exists before you attach the rule to any field.
- Which Laravel and PHP versions does version 2.x support?
- Check the constraints in the package's composer.json against the Laravel and PHP versions your application already pins before adopting it. Version 2.0.0 was a breaking major release, so anything still on 1.x needs a separate 1.x to 2.x upgrade review first. The 2.0.2 patch itself is additive relative to 2.0.1 and should not require code changes.
- How do I limit how many previous passwords are blocked?
- The rule accepts a limit so you can enforce policies like cannot reuse the last 3 passwords. You pass that number where you attach the rule inside a FormRequest or a manual Validator::make call. Keep the window realistic, since a larger history means more stored hashes are compared on every password change.
- Does it work with UUID or ULID user IDs instead of auto-increment integers?
- Yes. The 2.0.2 release added UUID primary key support so the history table can be keyed against users tables using HasUuids, ULIDs, or other non-integer identifiers. Before migrating, confirm the user_id column type in the migration matches your users table so the foreign key resolves correctly. This was previously a blocker for any app not on auto-increment integer IDs.
- How do I publish and customise the migration?
- Recent releases support publishing the migration into your own database/migrations directory, which lets you own the schema the same way you own the rest of your tables. That is the usual pattern for teams with schema governance, extra indexes, or shard-per-database multi-tenant setups. Publishing also puts the table definition in code review instead of hiding it behind the package's load path.
- Can I use it with Password::defaults() and Laravel FormRequests?
- It is a standard Laravel validation rule, so it runs anywhere the validator runs, including FormRequest rules, manual validators, and custom password rule objects. You can chain it alongside Password::defaults() and the built-in min, letters, mixed case, and uncompromised rules. Attach it to the forms where users actually set a new password, such as registration, password reset, and account settings.
- What about passwords users set before I installed the package?
- The package can only compare against passwords it has recorded, so accounts created before adoption have no history to check against. In practice the policy is soft-launched: a user is not blocked until they have changed their password at least once under the new rule. Treat that as an accepted product decision and make sure support and security teams understand the ramp-up period.
- How do I stop the password history table from growing forever?
- Every password change inserts a row, so the table grows with your reset and change volume over time. Decide up front whether your application or the package owns retention, and schedule a pruning job if nothing is provided. For most applications, deleting rows older than the longest policy window keeps the table small without weakening enforcement.
- Will history checks still pass if I change the hashing algorithm or HASH_DRIVER?
- History checks compare the new plain password against stored hashes with Hash::check, so they depend on the same hasher your authentication uses. If you rotate HASH_DRIVER or change hashing parameters, verify that old rows still validate, because bcrypt and argon hashes are not interchangeable. Document this in your runbook before scheduling any hashing migration.
- Is the package actively maintained, and can I fork or vendor it?
- The project has a small contributor base and a modest release cadence, so treat it as a bus-factor risk rather than a heavily staffed dependency. Its surface area is small, essentially one validation rule, one migration, and a config file, so vendoring or forking it is realistic if maintenance stalls. Pin an exact version and review the diff before upgrading instead of tracking a floating constraint.