- What does samasend/laravel-needs-auto-rehash actually do?
- It is a small Laravel service provider that listens on the framework's built-in authentication events. After a successful login it checks the stored hash with Hash::needsRehash and, if the hash no longer matches your current algorithm or cost settings, rehashes the plaintext credential and persists the new hash. It replaces the three-to-five line block that Laravel starter kits like Breeze, Jetstream and Fortify ask you to write by hand in the login path.
- How do I install laravel-needs-auto-rehash?
- Install it with composer require samasend/laravel-needs-auto-rehash. The service provider is auto-discovered, so there is no config file to publish, no migration to run and no assets to compile. If Composer reports a constraint conflict, that means the package does not resolve against your framework version rather than that you configured something wrong.
- Does this package support Laravel 11 and Laravel 12?
- Probably not. The last release was February 20, 2023, and the repository is archived, so the illuminate/* constraints almost certainly stop at Laravel 9 or 10. On Laravel 11 or 12 you should expect a dependency-resolution conflict, and forcing it with --with-all-dependencies is not advisable for a package sitting on the credential path.
- Is any configuration required to enable automatic rehashing?
- No, the package is zero-config by design: the listener is registered by the auto-discovered service provider and runs for every authentication attempt that reaches the bound event. There is no published config file, so you cannot easily disable it per-guard or per-context without editing the package itself. Confirm that limitation in the source before adopting it for multi-guard applications.
- Which authentication event does it listen on, and does that event receive the plaintext password?
- This is the single most important thing to verify in the source. Rehashing requires the plaintext credential, so the listener must bind to an event that actually carries it, such as Attempting or Validated, because Laravel's Login event does not include the password. If the listener is bound to an event without plaintext, the package cannot function as advertised.
- Will it rehash a password when a login attempt fails?
- It must not, and you should confirm this in the code before relying on it. A correct implementation is explicitly scoped to successful authentication only, typically by listening on a validated or login-success event rather than Attempting alone. If it fires on failed attempts it would write a hash of the wrong password, which is a data-corruption bug.
- Does the rehash use a targeted column update or a full model save?
- The package must write the new hash without clobbering concurrent changes to updated_at, other columns, observers or audit fields, and whether it uses update() or save() is the key detail to read. A full save() risks overwriting concurrent user-model writes, while a targeted update of the password column is safer. Check the listener source and test it against any model observers you rely on.
- What happens if rehashing throws an exception during login?
- If exceptions on the auth path are not caught and logged, a rehash or database failure becomes a login outage rather than a harmless skipped upgrade. A package like this should fail silently or log and continue, never propagate out of the authentication flow. Force a failure in staging, for example by breaking the hash column write, and observe what the user sees.
- Is it safe to run in production when the repository is archived?
- Treat it as a governance finding even though the exploit likelihood is low given the code volume. An archived, unmaintained package on the credential path means no CVE response, no compatibility fixes and no maintainer to ask, and there is no credible signal of CI or a test matrix across Laravel majors. Inspect the workflow files and test suite yourself before depending on it.
- Should I use this package or just implement the rehash logic in-house?
- The total functionality is roughly forty to sixty lines including tests, so reimplementing it in your login path is cheap and gives you full control over persistence and error handling. Vendor the package only if you accept the archived status and have verified the event binding and update semantics. The build-versus-fork question is really about whether you want to own an unmaintained dependency for a few lines of code.