Login Captcha Laravel Package

Product Decisions This Supports

• Security hardening of the internal admin surface. Dcat-admin login is a single, high-value door: it holds every back-office capability. A login captcha is a cheap, immediate mitigation against scripted credential-stuffing and brute-force attempts, and it is a common line item in security questionnaires and audit findings (SOC 2 / ISO 27001 "protection against brute force" controls). This package is the shortest path to closing that gap on a Dcat-admin installation.
• Build vs. buy. The functional scope is still thin: a captcha image field on the Dcat-admin login form, a validation rule, and (as of 1.0.11) a configurable captcha position. A senior Laravel engineer can reproduce it in well under a day using mews/captcha or gregwar/captcha. Buying only wins if the Dcat-admin-specific form hooks and config save you the integration/fiddling time — the decision hinges on time-to-ship, not on capability. The new position setting is a cosmetic config knob, not a reason to re-run the build-vs-buy analysis.
• Stopgap vs. strategic control. Captchas are a weak, user-hostile control compared with rate limiting, 2FA/TOTP, passkeys, or IP allowlisting. This package is best framed as a short-term checkbox you can ship in a sprint while the real roadmap item (2FA for admin accounts, or SSO) is scheduled and staffed.
• Scope and rollout decisions. Forces explicit answers to: which environments get it (recommend prod/staging only — leaving it on in local/CI breaks E2E and seeded-login tests), which panels/tenants (Dcat-admin only, so customer-facing or API login decisions go elsewhere), where the captcha renders on the login form (now configurable in 1.0.11 — a layout/UX nicety, not a security lever), and whether it's a permanent product surface or a temporary toggle.
• Vendor/dependency risk budgeting. With 32 stars, 0 dependents, and a release history that went quiet after March 2023, adopting this is a deliberate decision to own a small, slow-moving dependency — i.e., to pin, vendor, and potentially fork it. The 1.0.11 release is a single config-only addition (captcha position), which is a mildly positive maintenance signal but does not change the posture: assume you, not upstream, will fix breakage on framework upgrades. That is a resourcing decision, not just a composer require.

When to Consider This Package

Consider it when:

• You run Dcat-admin (verify against your major version — Dcat-admin 2.x) on a PHP/Laravel combination this package actually supports; compatibility is the first gate, not the feature list.
• You need a captcha specifically on the admin login form and want it configured, not coded, so a non-specialist can wire it up — including basic placement of the field (1.0.11+).
• You are comfortable treating it as frozen community code: pin the version in composer.json, vendor or fork it into your repo, and accept that you — not upstream — will fix breakage on framework upgrades.
• You need a fast, low-cost interim control for an audit or a security review, with 2FA or rate limiting on the near-term roadmap.
• Your admin population is small and internal, so the UX cost of a captcha is tolerable and accessibility exposure is limited.

Look elsewhere when:

• You are not on Dcat-admin, or you're on a Dcat/Laravel version newer than the package's release history covers — patch releases like 1.0.11 adding a config option are not evidence of compatibility testing against current framework majors, and with zero dependents no one has blazed the trail.
• Stronger controls are acceptable: Laravel's built-in throttle middleware, 2FA (laravel/fortify, pragmarx/google2fa), or SSO/IP allowlisting solve the same problem with better UX and better long-term maintenance.
• Accessibility is a requirement. Image captchas are a known WCAG friction point; audio/alternative flows are not part of this package's scope.
• You need long-term support, SLAs, or a maintainer who will respond to issues — 32 stars, no dependents, and a long gap followed by a one-line config release is a clear signal to plan for self-support.
• You would rather integrate mews/captcha directly behind a custom validation rule — a few dozen lines you fully own and can test.

How to Pitch It (Stakeholders)

For executives: This is a small, free, Apache-2.0 extension that puts a captcha on our Dcat-admin login page. It closes a standard audit finding — automated password-guessing against the back office — in roughly half a day of engineering, with no infrastructure cost and no vendor contract. The latest release (1.0.11) only adds a setting for where the captcha appears, so it changes nothing about the risk profile. The honest caveat stands: it is a low-adoption community package with a sparse release history, so we should treat it as a short-term control, pin the version internally, and pair it with the 2FA work already on the roadmap rather than relying on it as our permanent answer.

For engineering: One composer require, a config publish, a small amount of environment gating (off in local/CI so tests and seeded logins keep working), and — if you want it — the new captcha position option. Because upstream is effectively dormant, plan to pin the version, vendor or fork the code, and add a test asserting the captcha rule is active in production config. If we're already touching admin auth this quarter, the honest comparison is: a few dozen lines around mews/captcha, or this package for the Dcat-specific glue. Recommend it only if 2FA is not landing soon.