Weave Code
Extended Login Bundle Laravel Package
melk/extended-login-bundle
An extended login bundle for PHP applications that builds on standard authentication with configurable sign-in enhancements. It helps developers customize login behavior and add authentication flows with less boilerplate.
melk/extended-login-bundle adds flexible, configurable authentication flows to your Symfony application, extending the standard login process with additional checks, redirects, and user-friendly handling of edge cases. It is designed to drop into existing security setups with minimal configuration while staying out of the way of your own controllers and services.
- Extensible login flow with pluggable handlers and event hooks
- Configurable redirects for success, failure, and already-authenticated users
- Clear error handling for invalid credentials and locked accounts
- Service-oriented design that integrates with Symfony's security component
- Lightweight setup through bundle configuration and autowiring
Frequently asked questions about Extended Login Bundle
- Is melk/extended-login-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, despite frequently being listed alongside Laravel packages. The ...Bundle suffix, the DI extension and CompilerPass pattern, and the form-login integration all target Symfony's security stack. There is no Laravel service provider, no publishable config file, no Auth::viaRequest or guard integration, and no extra.laravel block in Composer. Treat it as a design reference for Laravel work, never as a dependency.
- Which Symfony versions and authentication mechanisms does the bundle support?
- The last release was 2020-07-31, so the realistic target is Symfony 3.4 through 4.4 using form_login or the Guard system. Guard was deprecated in 5.3 and removed in 6.0 in favour of AuthenticatorInterface, so a modern Symfony 6 or 7 host will need a port rather than a composer require. Verify the version constraints in composer.json against your runtime before planning anything.
- How do I install and configure it in a Symfony application?
- Installation follows the normal bundle flow: require the package with Composer, register the bundle in config/bundles.php, and import its service configuration through the DI extension. Because attempts, thresholds and the captcha provider likely live in bundle configuration, read the extension class and any config tree before editing YAML. The README excerpt is thin, so plan to audit the service definitions to see which parameters are actually consumed.
- Can I use this bundle in a Laravel application?
- No. Nothing in the package hooks Laravel's authentication pipeline, so installing it would add dead code and an unmaintained captcha dependency for zero benefit. The value here is the policy it encodes: show a challenge after N sequential failures, reset the counter on success, and gate the challenge before credential validation. In Laravel that policy maps onto RateLimiter, a login request listener or a Fortify action, and a Blade partial.
- How do I add a captcha after several failed login attempts in Laravel?
- Use RateLimiter::tooManyAttempts on a key built from the email plus IP, and when the threshold is crossed, validate a Turnstile or hCaptcha token before calling Auth::attempt. Hit RateLimiter::hit on each failure and RateLimiter::clear on success so the challenge disappears after a good login. Render the challenge with a Blade partial included conditionally in your login view. The whole feature is a few hundred lines, which is why reimplementing beats adopting an abandoned Symfony bundle.
- Where does the bundle store the failed-login attempt counter?
- The storage backend is the single most important thing to confirm in a source audit, because it determines whether the control is enforceable at all. Session-backed counters are trivially reset by clearing cookies, while cache or database counters shared across nodes actually hold. If counters are keyed by IP, check for lockout and denial-of-service risk behind NAT or shared corporate egress, where one attacker can lock out an entire office.
- Is this package safe to run in production?
- Assume not until proven otherwise. It has zero stars, zero dependents, no release in roughly four years, and no documented security disclosure process, yet it sits directly on the authentication path, which is the highest blast-radius code in any application. Any adoption should start with a full source audit covering the auth flow, counter storage, output escaping and timing behaviour. If you fork it, vendor it under an internal namespace and assign a named owner.
- Which captcha library does it use, and is that dependency still maintained?
- The bundle relies on an external captcha package, most likely an image-based GD or Imagick library, and that pinned dependency is a bigger risk than the bundle itself. Image captchas age badly across PHP upgrades and are increasingly rejected on accessibility grounds. Confirm independently whether the chosen library supports PHP 8.1 and later, and consider swapping to Cloudflare Turnstile or hCaptcha if you port the logic.
- Should I fork the bundle or reimplement the feature?
- Default to reimplementing if your host is Laravel or Symfony 5.4 and above, since the authentication plumbing will not survive an upgrade and the underlying logic is small. Forking is only reasonable on a Symfony 4.4 or 5.x host where the Guard-based integration still works and the migration cost is genuinely lower. Either way, settle the attempt-count storage design first, because shared Redis or database state changes the integration shape more than the captcha choice.
- How do I test a captcha-after-failed-logins flow?
- There is no CI configuration or test suite to rely on, so build coverage yourself around the failure path: N minus one failures should pass without a challenge, the Nth should require one, and a successful login must clear the counter. Test the challenge bypass attempt where a valid password is submitted with a missing or invalid token, and test counter expiry. In Laravel, RateLimiter's time-based decay means you can assert reset behaviour with travel or sleep-free time helpers instead of real waits.
Weaver
How can I help you explore Laravel packages today?