Extended Login Bundle Laravel Package

Getting Started

Framework mismatch first. melk/extended-login-bundle is a Symfony bundle (Composer type symfony-bundle), not a Laravel package. There is no service provider, no config/ publish tag, and nothing for Laravel's container to boot. If you are in a Laravel codebase, installing it gets you an autoloaded namespace and nothing else — you would be porting the logic (failure counter + captcha gate), not using the package. Read the rest of this as "what a developer would actually do when this lands in a repo."

If you are in a Symfony project:

1. composer require melk/extended-login-bundle and pin the version — the only release is 2020-07-31.
2. Register the bundle in config/bundles.php (Symfony 4/5 Flex era): Melk\ExtendedLoginBundle\MelkExtendedLoginBundle::class => ['all' => true].
3. Check composer.json constraints before anything else — expect PHP 7.x and symfony/framework-bundle ^3.4|^4.0|^5.0. On PHP 8.1+/Symfony 6 expect Bundle::load() / getContainerExtension() return-type deprecations.

Where to look first, in order:

• DependencyInjection/Configuration.php — the authoritative config tree. Trust this over the README; 2020-era docs drift fast.
• Resources/config/services.* — real service IDs and decorator targets.
• Resources/views/ — the login template it overrides (this is where the captcha field appears).
• EventListener/ or Security/ — the failure counter. This is the part you will almost certainly patch.

First use case: on a form_login firewall, count failed attempts per user/IP and, past a threshold, replace the standard login form with one requiring a captcha — rejecting authentication without a valid captcha response. Wire it against an existing firewall rather than adding a second authenticator.

Implementation Patterns

• Hook the existing firewall, don't duplicate auth. The bundle is a presentation-and-gate layer over form_login/json_login. Adding a second authenticator to the same firewall produces confusing ordering and double failure events.
• Counter storage is the design decision. Expect a session- or cache-backed counter keyed by username + IP. If you run more than one app node, confirm it uses a shared cache pool (CacheItemPoolInterface) — if it falls back to session/filesystem, your "N failures" threshold becomes per-node and per-session, which silently defeats the feature.
• Template override is the branding seam. Override the bundle's security/login view through your app's templates/ (or twig.paths) to style the captcha and show a "too many attempts, complete the captcha" message only past the threshold.
• Configure through the bundle alias, e.g. melk_extended_login: { attempts: 3, ... } — the exact keys come from Configuration.php. Set them in config/packages/*.yaml per environment; keep the threshold low in prod, effectively off in test.
• Stateless/API firewalls: use json_login and return a machine-readable error ({ "captcha_required": true }) so the client can fetch a captcha and retry. Do not redirect a JSON client to an HTML form.
• Functional test as acceptance criteria: N bad-password POSTs to login_check, assert 200 with a captcha field (or 302 back with error), then a good password + valid captcha succeeds. Stub the captcha validator rather than solving an image in tests.
• Pick one counter. If you also enable Symfony's native login_throttling, decide which one owns the lockout and which owns the captcha prompt. Two counters reacting to the same failure event is a common source of "locked out forever" bugs.

Gotchas and Tips

• Maintenance is the headline risk. 0 stars, 0 dependents, last release July 2020. Treat this as vendored source: fork it into your app namespace, or reimplement — a failure listener, a cache-backed counter, and a form type with a captcha is roughly 60 lines. A Laravel dev's instinct (RateLimiter::tooManyAttempts() + a captcha validation rule in LoginController) is the correct shape of the fix; do not try to bridge this bundle into Laravel's auth pipeline.
• Symfony security internals moved. 5.3+/6 reworked the form login listener, deprecated guard, and reshuffled authentication events. Code written against 4.x security.authentication.failure / UsernamePasswordFormAuthenticationListener will need patching. Budget for it.
• Captcha dependency and GD. Check composer.json for gregwar/captcha (or similar). Those libraries need GD/imagick and often write to the filesystem. Verify the container has the extension and the temp dir is writable — this fails silently-ish at runtime, not install time.
• Keying the counter is a footgun. Key by IP only → shared NATs lock out whole offices. Key by username only → trivial spray/enumeration. Verify what it keys on, and verify a successful login clears the counter.
• Event priority matters. If you have your own LoginFailureEvent listener or throttling, check getSubscribedEvents() priorities in debug:event-dispatcher before assuming your listener sees the increment.
• Debugging commands that actually help:
  • bin/console debug:config melk_extended_login — confirms your YAML is reaching the config tree.
  • bin/console debug:container --tag=kernel.event_subscriber | grep -i melk — confirms the listener is registered.
  • bin/console debug:router | grep login — confirms the gate is on the route you think.
  • dump() inside the failure listener to confirm counters increment and where they reset.
• Extend, don't edit vendor/. Swap the listener class or template via services.yaml aliasing; if the bundle doesn't expose it as a service you can override, that's your signal to fork rather than patch.
• Security framing: captcha-after-N-failures mitigates credential stuffing UX-wise but is not a control by itself. Pair it with rate limiting (Symfony login_throttling or the reverse proxy) and MFA for privileged accounts.
• Read the released tag's code, not the default branch. With a single 2020 release and no activity since, master and the tag may diverge; composer show -a melk/extended-login-bundle tells you what you actually have.