- What does pushery/fortify-hardening-for-laravel do?
- It adds opinionated security hardening to Laravel Fortify without replacing Fortify's authentication flows. The package enforces stronger password and credential policies, adds rate limiting and lockout protections, hardens two-factor and sensitive-action flows, invalidates sessions and tokens on security events, and provides publishable configuration for app-specific tuning. It is aimed at Laravel teams already using Fortify that want safer defaults with minimal configuration.
- Does this package replace Laravel Fortify's login, registration, or two-factor flows?
- No. It layers configurable guards and safer defaults on top of Fortify, so you keep Fortify's existing authentication features. The hardening is applied to login, registration, password reset, two-factor, and sensitive-action behavior rather than replacing those flows. You should still review the published configuration to tune behavior for your app.
- Which Laravel, Fortify, PHP, and Livewire versions are supported?
- The provided material does not list exact version constraints, and the package is pre-1.0 and bound to Fortify internals. Check the repository's composer.json for the supported Laravel, Fortify, and PHP ranges before adopting it. Livewire is relevant to the Livewire-aware assertEnumerationSafe() test helper in v0.3.0, so confirm whether it is required as a dev dependency for your test suite.
- How do I install and configure pushery/fortify-hardening-for-laravel?
- Installation is typically a Composer update plus publishing the package configuration and translations. After publishing, review keys such as fortify-hardening.registration.notification and fortify-hardening.registration.notice_mentions_password_reset. Verify the configuration behaves correctly under config cache and that any custom notification subclass is autoloadable and constructed with the expected contract.
- How does it improve login throttling and lockout protection?
- It adds rate limiting and lockout protections around Fortify authentication flows. v0.2.0 specifically addressed login rate-limit key privacy, which matters if keys could expose sensitive values. In production, remember that mixed-version rolling deploys can split rate-limit counters across nodes, so plan deployments carefully.
- How does it handle two-factor authentication and sensitive-action flows?
- The package hardens two-factor and sensitive-action flows through configurable guards and safer defaults. It can also invalidate sessions and tokens when security events occur, reducing the chance that stale sessions remain valid. It does not replace Fortify's two-factor implementation, so you keep Fortify features while tightening behavior.
- How does v0.3.0 address registration enumeration?
- v0.3.0 sends a notice to the holder of an already-registered email address, helping registration behave more consistently without revealing whether an address exists to the registering party. The notice names the application in its subject via app.name, and a configurable subclass can override applicationName() and greeting() for multi-instance installs. A fortify-hardening.registration.notice_mentions_password_reset flag stops the notice from suggesting a password reset in passwordless applications.
- Does assertEnumerationSafe() support Livewire registration forms?
- Yes. The v0.3.0 helper fingerprints snapshots without checksums, normalizes generated component IDs to <component-id>, and replaces echoed identities with <identity> across status, errors, and redirects. It likely requires Livewire test utilities and may require updating tests that compared raw JSON byte for byte. Verify with a deliberate known-vs-unknown difference that a genuine differential field still fails the assertion.
- Are the registration notice translations complete across supported languages?
- The package supports seven languages, but translation coverage must be validated for the new registration notice. Check that the :app placeholder is present and rendered correctly in every locale. Also confirm whether the notice is sent synchronously in the registration request path or queued, because synchronous mail changes latency and failure behavior.
- What production and maintenance risks should I consider before adopting it?
- Treat it as security-sensitive infrastructure: it is pre-1.0 and bound to Fortify internals. Production checks include stale config cache, APP_KEY rotation or node mismatch, mixed-version rolling deploys splitting rate-limit counters, and historical raw email/IP data in cache or error-tracker telemetry. The notification subclass contract is an extension point that may shift before 1.0, and outbound notices can be abused for mail bombing, so consider rate limiting and monitoring. If your app does not use Fortify or has fully custom registration and throttling, fit is low.