Extended Login Bundle Laravel Package

Technical Evaluation

Architecture fit

• Despite the framing in the request, this is a Symfony bundle, not a Laravel package. The ...Bundle suffix, the DI extension/CompilerPass pattern, and the form-login integration target Symfony's security stack. There is no Laravel service provider, no publishable config, no guard/Auth::viaRequest integration, and no Composer extra.laravel block. On a Laravel codebase this is a reimplementation reference, not a dependency.
• On Symfony it hooks the authentication layer — most likely the form-login listener or the Guard system. Both have since moved: Guard was deprecated in 5.3 and removed in 6.0, replaced by AuthenticatorInterface. A bundle last released 2020-07-31 almost certainly targets Symfony 3.4–4.4 and will not survive a modern Symfony upgrade without porting.
• The underlying feature — require a captcha after N sequential failed logins, reset on success — is a small amount of logic (attempt counter, threshold check, challenge render/validate, reset hook). Most implementations are a few hundred lines.

Integration feasibility

Low-to-moderate. Zero stars, zero dependents, and a 0.03 score mean there is no field validation whatsoever — no production users to infer stability from, no downstream issues to search, no forks carrying fixes. Any adoption begins with a full source audit, not a composer require.

Technical risk

• Abandonment: no release in ~4 years, no security disclosure process, and it sits directly on the authentication path — the highest-blast-radius code in the application.
• Captcha dependency: image-captcha libraries (GD/Imagick-based) age badly across PHP upgrades and are increasingly rejected on accessibility grounds. The pinned captcha package is a larger risk than the bundle itself.
• PHP compatibility: 2020-era constraints likely cap at PHP 7.x; expect deprecation noise or hard failures on 8.1+.
• Counter storage unknown: whether attempts are tracked in session, cache, or DB determines whether the control is actually enforceable.

Key questions

1. Is the host application Symfony or Laravel? This single answer decides between "vendor and fork" and "do not use."
2. Which Symfony version and which auth mechanism (form_login, Guard, or new authenticators)?
3. Which captcha library and provider, and is it still maintained? Self-hosted image, reCAPTCHA, or Turnstile?
4. Are attempt counters keyed per-user, per-IP, or both — and stored where?
5. Is there a DoS/lockout vector from IP-keyed counters behind NAT or shared egress?
6. Are there tests, and is there a CI config? (Assume no until verified.)

Integration Approach

Stack fit

• Symfony 4.4/5.x host: fork-and-vendor is viable. Import under an internal namespace, pin the captcha dependency, and treat it as first-party code.
• Laravel host: do not adapt. The bundle's value is the policy (threshold, reset semantics, challenge placement), not the code. Reimplement natively — Laravel ships the primitives already: RateLimiter, a login-request listener or Fortify action, and a Blade partial for the challenge. Prefer Cloudflare Turnstile or hCaptcha over a self-hosted image captcha for accessibility and to avoid GD dependencies.

Migration path

1. Source audit of the bundle (auth flow, storage, escaping, timing).
2. Branch spike wired into a non-production environment.
3. Decision gate: fork vs. reimplement — default to reimplement if the host is Laravel or Symfony ≥ 5.4.
4. If forking: internal namespace, pinned versions, added tests around the failure path, and a documented owner.

Compatibility

Confirm PHP constraint against the target runtime, Symfony deprecation surface, and whether the bundle overrides Twig login templates (template overrides are a common upgrade breakage point). Verify the captcha library's PHP 8 support independently.

Sequencing

Land the audit and a working spike before committing to the dependency. Attempt-count storage design (shared Redis/DB vs. session) should be settled up front, since it changes the integration shape more than the captcha choice does.

Operational Impact

Maintenance

Effectively total ownership. With no upstream activity since July 2020, budget for it as internal code: dependency bumps, PHP/Symfony upgrade work, and periodic security review of the auth path. A reimplementation is typically cheaper to own than a fork of unfamiliar, untested auth code.

Support

No community, no issue triage, no CVE channel, no maintainer response path. For a security-adjacent control this is the dominant risk — not the code quality.

Scaling

Attempt counters must be shared across application servers (Redis or DB), not session-scoped, or the captcha can be bypassed by hitting a different node mid-sequence. Decide and document per-user vs. per-IP keying; per-IP under shared NAT creates false positives at scale, per-user alone allows credential-stuffing breadth.

Failure modes

• Captcha provider outage → login is blocked entirely. Choose fail-open vs. fail-closed explicitly and document it; the safe default for most B2C products is fail-open with alerting, not a hard lockout.
• Counter store outage → captcha silently disabled or every login challenged; both need monitoring.
• Accessibility → image captchas fail WCAG expectations and generate support load; an argument for a managed challenge.
• Threshold tuning → too low frustrates legitimate users and inflates helpdesk tickets; too high weakens the control.

Ramp-up

Low for the feature concept, moderate for the code if forking (unfamiliar, undocumented, no tests). If reimplementing, expect roughly 1–3 engineer-days including tests and accessibility review — small enough that the abandonment risk dominates the build-cost argument.

Recommendation: do not adopt as a dependency. Use it as a design reference and implement the threshold-plus-captcha policy natively on the target framework.