Think Captcha Laravel Package

Product Decisions This Supports

• Build vs. buy for human-verification on ThinkPHP stacks. This package answers the narrow, recurring question "do we hand-roll image CAPTCHA for our ThinkPHP admin/login forms, or drop in a maintained helper?" It bundles image generation, session-backed code storage, and a check() verification call — roughly 100–200 lines of code you would otherwise own, test, and patch. Buying (or rather, adopting) wins on time-to-ship for internal tools; building wins only if you need custom challenge types.
• Scoping an anti-bot tier on the roadmap. Use it as the "cheap tier" in a layered defence story: CAPTCHA on auth and public form endpoints, rate limiting and WAF rules behind it. It informs sequencing decisions — image CAPTCHA now, invisible/behavioural or third-party risk scoring later if abuse metrics justify the cost.
• Prioritising form-abuse work in the backlog. Concrete adoption trigger: rising junk submissions on registration, password reset, comment, or contact forms. This maps directly to a user story ("as an ops owner I want fewer bot-created accounts") that is easy to estimate and ship.
• Platform-consistency decision. This is a ThinkPHP library, not a Laravel one. That matters for portfolio decisions: if the product is Laravel, this is not the package — you would be choosing between mews/captcha, gregwar/captcha, or a hosted provider (hCaptcha/Turnstile). The decision this supports is "which framework-consistent default do we standardise on," and the answer here is ThinkPHP-only.
• Accessibility and support-cost tradeoff. Image CAPTCHAs impose a measurable accessibility and completion-rate cost. Adopting this locks in a visual challenge, so it forces an explicit roadmap item for an audio alternative or a fallback path — worth deciding up front rather than after a support escalation.
• Risk-register entry, not a feature bet. With 117 stars, 0 dependents, and an ambiguous NOASSERTION licence, this is a convenience dependency, not an ecosystem commitment. That distinction should drive the decision: adopt it behind an interface you control, so it is swappable.

When to Consider This Package

Consider it when:

• The application is ThinkPHP 6/8 (or a legacy ThinkPHP app being maintained), which is the only context where this package is idiomatic.
• You need a fast, self-hosted image CAPTCHA for login, registration, or public form endpoints and do not want a third-party JS dependency or an external network call on the auth path — relevant where privacy, offline deployment, or China-region latency/reachability makes hCaptcha or reCAPTCHA unattractive.
• The threat model is low-to-moderate: opportunistic scrapers and scripted form spam, not targeted adversaries. Image CAPTCHAs are solvable by farming services; treat this as friction, not a boundary.
• You want zero external service cost and are willing to own a thin abstraction layer around it.

Look elsewhere when:

• The stack is Laravel. This package will not integrate; pick a Laravel-native option or a hosted challenge provider. Do not force cross-framework parity here.
• The licence question is unresolved. NOASSERTION is an assessment blocker, not a footnote — legal should confirm redistribution and commercial-use terms before this ships in a distributed or client-delivered product. If legal cannot get a clear answer, treat it as unadoptable.
• You need modern bot defence. Behavioural signals, risk scoring, and passkey/Turnstile-style invisible challenges outperform image CAPTCHA on both security and conversion. If abuse is a real revenue or trust problem, spend the integration effort here instead.
• Accessibility is a hard requirement (WCAG 2.2 AA, public-sector or regulated contexts). A visual-only challenge needs a documented alternative; if the package's audio path is untested or absent, you inherit that gap.
• You need maintainer responsiveness or a security SLA. 117 stars and zero dependents means a very thin community: essentially one upstream maintainer, limited peer review, and no downstream bug reports to learn from. Budget for vendoring/forking if the project is business-critical.
• Heavy traffic or horizontal scale is expected. Session-backed CAPTCHA couples verification to session affinity; verify the storage model against your load-balanced topology before committing.

Net PM read: a reasonable, low-cost convenience for a ThinkPHP monolith — adopt with a wrapper interface, a licence clearance, and a scheduled re-evaluation point. Do not let it onto the roadmap as the long-term answer to bot traffic.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, self-hosted CAPTCHA component for our ThinkPHP application. It lets us put human verification on login and public forms in a few days rather than a few weeks, with no per-request vendor fees and no data leaving our infrastructure. The tradeoffs are honest ones: it is a niche open-source component with a single maintainer and an unclear licence, and image CAPTCHAs are a speed bump, not a wall. My recommendation is to use it as a tactical fix, wrap it so we can replace it without touching product code, and clear the licence with legal before it goes anywhere client-facing. It is not the strategic answer to bot traffic — that decision is still open, and I would bring a hosted or behavioural option back once we have abuse numbers.

For engineering: Small ThinkPHP 6/8 library — generates a CAPTCHA image, stores the code in session, exposes a check() verification call. Integration is low effort: route, controller action, a form field, and a middleware or manual check on the protected endpoint. Two constraints to design around: (1) it is framework-specific — no Laravel path, so if we are multi-framework we need a thin CaptchaVerifier interface with per-framework implementations; (2) session coupling means we must confirm it behaves under our load-balanced, multi-instance setup, or move to a shared session store. Licence is NOASSERTION — flagging for legal before we vendor it. Pin the version, note the 2024-11-22 release date, and plan to fork if we need patches. I would also add a task to test the audio/accessibility path, since that is the most likely place this bites us in production.

One-line justification for the roadmap: lowest-effort, zero-marginal-cost reduction in automated form abuse on our ThinkPHP surface — adopted as an interim control, with a wrapper and an explicit re-evaluation date.