Gentle Force Bundle Laravel Package

Technical Evaluation

Architecture fit. maba/gentle-force-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle class, a DependencyInjection extension for the maba_gentle_force config tree, and event subscribers wired into Symfony's security.authentication.failure flow. None of that bootstraps under Laravel's service container. The only realistic leverage for a Laravel-centric org is as a reference design for three limiter primitives: brute-force (credential-stuffing), error-rate (4xx/5xx anomaly), and request-rate (generic throttle), backed by a swappable storage interface with cache-based and Doctrine/ORM-based implementations.

Integration feasibility — low. Three paths, ranked by effort:

1. Reimplement the concepts natively (~2–4 dev-days) using Illuminate\Cache\RateLimiter + the throttle middleware + a listener on Illuminate\Auth\Events\Failed. Covers brute-force and request-rate at parity; the error-rate limiter is a small custom middleware.
2. Port the bundle into a Laravel package by re-homing the throttling core (storage contract + decision object) behind a service provider. ~2–3 weeks including tests.
3. Run Symfony alongside Laravel — not justified for a limiter.

Technical risk — high for anything touching authentication.

• Unmaintained: no tagged release since 2021-08-26. Symfony 6/7 support is unverified; the event and DI wiring targets the Symfony 4.4/5.x era.
• Adoption signal is effectively zero: 50 stars, 0 dependents. No downstream cohort to absorb breakage or publish fixes.
• Bus factor 1 (single author), MIT, no visible security policy. Shipping a stale dependency directly on the login path is a supply-chain exposure we would have to own ourselves.
• Opportunity score 27.73 corroborates this: limited upside, and the mature alternatives (symfony/rate-limiter, Symfony's built-in login throttling, Laravel's RateLimiter) already cover the bulk of the functionality.

Key questions for the maintainer/owner.

• Is there a supported version matrix for PHP 8.2+/Symfony 6.4/7.x, or is the project sunset?
• What is the disclosure process for a limiter bypass or counter-reset bug?
• Which storage backends are production-hardened — cache only, or is the Doctrine path expected at scale?
• How are client keys derived behind a CDN/proxy (trusted-proxy handling), and is there a fail-open/fail-closed switch?
• Does the error-rate limiter observe responses (kernel.terminate) or block pre-flight?

Recommendation: do not adopt as a dependency. Treat it as a design reference and build the three limiters on Laravel primitives. Revisit only if we introduce a Symfony service.

Integration Approach

Stack fit. If the target is Laravel: native RateLimiter + Redis store, throttle: middleware, and a Failed-event listener with an exponential backoff keyed on email|ip. The bundle's differentiator — a unified abstraction across three limiter types plus captcha escalation — is reproducible in ~200 lines and inherits framework support guarantees.

Migration path. (1) Inventory current auth endpoints and abuse signals. (2) Implement request-rate first (lowest blast radius, throttle middleware). (3) Add brute-force on Illuminate\Auth\Events\Failed with per-identifier and per-IP buckets. (4) Add error-rate last, since it needs response observation and careful exclusions.

Compatibility. The bundle's PHP 7.x/8.0-era constraints and Symfony 4.4/5.x wiring do not align with a modern Laravel runtime; expect to vendor and patch rather than composer require. If a Symfony port is genuinely on the table, prefer symfony/rate-limiter (actively maintained, same conceptual model) and Symfony's native login throttling.

Sequencing. Shadow mode first — emit limiter decisions as metrics without enforcing, for 2–3 weeks, to tune thresholds and confirm key cardinality. Then enforce on login only. Then extend to API and error-rate. Gate each stage behind a feature flag so rollback is a config change, not a deploy.

Operational Impact

Maintenance. Zero upstream velocity. Any bug we hit is ours to fix; the fork becomes a permanent liability on an authentication-critical path. Budget ongoing ownership rather than assuming community support.

Support. Community-only, single maintainer, no SLA, no security channel. Escalation path is a GitHub issue on a repo with 50 stars.

Scaling. Storage choice dominates. A cache/Redis backend scales horizontally and is the only viable option for multi-node deployments. The Doctrine/ORM backend writes a row per attempt — under credential-stuffing load that means hot-row contention and lock waits on the exact table you need responsive during an incident. Counter cardinality also matters: unbounded keys (raw email, raw IP) inflate Redis memory and need TTL discipline.

Failure modes.

• Fail-open vs fail-closed: cache outage either disables protection or locks out all users. Must be an explicit, documented decision with an alert.
• Key collapse behind proxies: if the client IP resolves to the load balancer, every user shares one bucket — a self-inflicted global lockout.
• Lockout-as-DoS: attacker-driven lockouts of known accounts are a real product risk; prefer exponential delay over hard lock.
• Counter reset: cache eviction or a Redis flush silently resets protection mid-attack.
• Clock skew across nodes where windows are computed locally.

Ramp-up. The API surface is small and legible — a mid-level engineer can extract the design in a day and reach a production PoC in 2–4 days. The real ramp-up cost is organizational: agreeing thresholds, defining what "abuse" means per endpoint, and wiring alerting on limiter trips. That work is identical whether we adopt the bundle or reimplement, which further weakens the case for the dependency.