hypervel / fortify

0.4.x-dev 2026-10-13 03:23 UTC

Requires

• php: ^8.4
• chillerlan/php-qrcode: ^6.0
• hypervel/auth: ^0.4
• hypervel/collections: ^0.4
• hypervel/config: ^0.4
• hypervel/console: ^0.4
• hypervel/container: ^0.4
• hypervel/contracts: ^0.4
• hypervel/database: ^0.4
• hypervel/encryption: ^0.4
• hypervel/events: ^0.4
• hypervel/filesystem: ^0.4
• hypervel/foundation: ^0.4
• hypervel/hashing: ^0.4
• hypervel/http: ^0.4
• hypervel/passkeys: ^0.4
• hypervel/queue: ^0.4
• hypervel/rate-limiter: ^0.4
• hypervel/routing: ^0.4
• hypervel/session: ^0.4
• hypervel/support: ^0.4
• hypervel/translation: ^0.4
• hypervel/validation: ^0.4
• hypervel/view: ^0.4
• psr/clock: ^1.0
• spomky-labs/otphp: ^11.0
• symfony/console: ^8.1.2
• symfony/http-foundation: ^8.1

MIT

• Albert Chen
• Raj Siva-Rajah

• php
• auth
• swoole
• fortify
• hypervel

Published on Packagist.org on 2026-10-27 07:30 UTC

README

Documentation: https://hypervel.org/docs/fortify

Differences From Laravel

• Fortify follows Hypervel's current default guard selected by Auth::shouldUse() or auth.defaults.guard, with optional fortify.guard route-group selection for built-in routes.
• Fortify uses the password reset broker declared by the selected guard's passwords key instead of using a separate Fortify broker setting.
• Fortify integrates with the standalone hypervel/passkeys package and keeps passkeys polymorphic across authenticatable model classes.
• Fortify supports boot-time request-aware redirect callbacks for dynamic post-login destinations, such as for custom domains, multi-guard apps, or multi-tenant apps.
• Fortify throttles two-factor challenge submissions by default.
• Fortify scopes login throttling per guard (guard|username|ip), so a lockout in one actor silo never blocks logins in another.
• Fortify password confirmation follows the current guard: guard-scoped session key, optional per-guard password_timeout, and the confirmed-password status endpoint uses the same resolution. This also unifies Laravel's mismatched 900/10800 fallback defaults.
• Fortify's two-factor provider uses OTPHP instead of Google2FA and generates 32-character secrets by default.
• Two-factor user models implement the TwoFactorAuthenticationUser contract as well as using the TwoFactorAuthenticatable trait. Recovery codes are consumed atomically through the user's consumeRecoveryCode() method; TwoFactorLoginRequest::validRecoveryCode() only checks a code and leaves the login challenge in the session.
• Fortify omits Laravel's deprecated Rules\Password.
• Fortify keeps Laravel's directly writable static configuration properties private so worker-lifetime state remains typed and resettable. Use authenticateThrough(), authenticateUsing(), confirmPasswordsUsing(), generateRecoveryCodesUsing(), encryptUsing(), and ignoreRoutes() instead.

Ported from: https://github.com/laravel/fortify