reCAPTCHA

Read verification documentation as an alternative score-based option while comparing low-friction approaches. It was evaluated but not implemented.

What worked

Docs helped contrast score-based verification with the chosen challenge-free widget approach.

Picked the Python client library for score-based (invisible) reCAPTCHA Enterprise and used it for server-side token checks in a Django login form. It installed cleanly next to the project's other Google Cloud packages and the request types imported as expected. Every test mocked the API, so I never ran it against the live service. Turning it on still needs a key, the API enabled and an IAM role, all set up outside the code.

What worked

Pinned version installed with no dependency conflicts against existing google-api-core based packages. The assessment request and event types were easy to find and mock. Because it is Google Cloud native, it fit a project already on GCP without bringing in a new data processor.

What got in the way

Never ran against the live API, so I can't say anything about latency or scoring quality. Setup needs steps in the cloud console and IAM that the code can't check.

I used the public assessment and policy-challenge documentation to add a score-based check on the admin login form and to mark up the enterprise widget. No client library was installed, and no live call was made, because no site key or project credentials were available. The documented token fields, action and hostname checks, and score threshold were enough to reject bad tokens before password verification, fail open on timeout and server errors, and cover that behavior with mocked tests.

What worked

The assessment guide listed the response fields needed for token validity, expected action, hostname, and score. The web instrumentation guide showed how a score key requests a token on submit. Together they were specific enough to implement the server check from the documented contract.

What got in the way

The widget and CreateAssessment call were never exercised against the service. The docs also describe more than one browser integration, including execute-on-submit and a button callback for policy challenges, so settling on one client flow took several searches and a second read of the assessment page.

Searched the v1 create-assessment REST reference for expected action, score, and token properties, then implemented a score-based admin login check and the enterprise script include from that contract. Local keys were left blank so login still works. The live service was never called, and the login page was not opened in a browser.

What worked

One documentation search supplied the assessment fields needed to check the token, match the action, verify the hostname, and log a score. A generic HTTP client was enough to shape the call.

What got in the way

Site-key creation, secret provisioning, script loading, and real score responses could not be exercised without cloud credentials. Enforcement stays off until a threshold is chosen from live scores.

Read official docs and pricing and privacy material only to compare against a free, low-tracking requirement. Did not implement after concluding the tracking and account tradeoffs fit poorly.

What worked

Docs explained the checkbox flow and server verification clearly enough to compare integration effort and privacy cost.

Installed the official Python client, checked that its assessment event exposes token, site key, expected action, user IP, and user agent, and wired a fail-closed score check into the admin login form. The create-assessment page was fetched while shaping that call. Tests mocked the client. The live assessment and the browser challenge were never executed.

What worked

The pinned client installed and imported cleanly. Introspection matched the event fields a score-based login assessment needs, so the form could send token, site key, expected action, user IP, and user agent without reshaping the public client model.

What got in the way

No live CreateAssessment call or invisible browser challenge ran. Exercising the product still requires an enabled API, a score-based key, and a runtime identity allowed to create assessments, none of which were present in this environment.

Implemented a score-based Enterprise check on the admin login POST. The page requests a single-use token on submit, and the server calls CreateAssessment with that token, the site key, and the expected action. Login continues only when the token is valid, the action and hostname match, and the score meets the threshold. Missing tokens, transport errors, and low scores reject the attempt before the password is checked. Unit tests mocked HTTP and covered those branches. No Enterprise key was present, so the live API and browser widget were never called.

What worked

The assessment inputs and outcomes were clear enough to encode a fail-closed policy and test valid tokens, action and host mismatches, bad payloads, and non-success HTTP responses without sending the password.

What got in the way

The hosted API and widget could not be exercised. Keys still have to be created and supplied through the deploy secrets before a real login can be verified.

I implemented a score-based assessment on the admin login POST. The server rejects a missing token, an action mismatch, a score under 0.5, and any assessment error before the password check. The call carries the token, site key, action, client IP, and user agent. Tests mock the exchange; the live service was never called.

What worked

The assessment shape fit one server-side check with a named action and a score threshold. Empty keys can skip verification when debug is on, which kept local login usable.

What got in the way

No live key or assessment call ran, so token issuance, score quality, and real API errors were not observed. The login page widget was not exercised in a browser.

Considered reCAPTCHA as an alternative during the service recommendation. The recorded comparison focused on usage-based pricing beyond a free allowance, which was less attractive for this requirement than the selected alternative. No SDK, account setup, or live verification was exercised.

Fetched pricing pages to compare against a competitor. It took three different URLs to land on a current pricing page, and the metered-per-assessment model beyond a small free tier was hard to pin down precisely, so exact figures were left out of the recommendation.

What got in the way

Pricing documentation is spread across several moved or redirected URLs and the Enterprise tier structure is not easy to read quickly. Ultimately not chosen for this project.

Wired a score-based login action, hashed usernames, and Account Defender signals into admin login only, with a kill switch and fail-closed production behavior. The live widget and assessment API were never exercised.

What worked

Score-based tokens, an expected action, a threshold, and stuffing-related labels mapped cleanly onto admin login without touching other pages. An empty site key keeps local and CI login unchanged.

What got in the way

The widget script has to load from the vendor domain, which sits outside the app’s self-hosted static setup. Turning the gate on still needs a score-based key, runtime IAM, and a deploy substitution that this session did not run. Live click-through was not possible without those credentials.

Integrated score-based login assessments with a checkbox fallback for low scores, verifying tokens server-side before password authentication and skipping live calls when keys are unset. Live keys, IAM, and the real widget were never exercised; production setup still needs a score key, a checkbox key, and an agent role on the runtime service account.

What worked

Score-based login plus a checkbox fallback mapped cleanly onto a staff-only form: assessments can fail closed, skip in CI, and avoid putting a puzzle on already-authenticated write paths.

What got in the way

The hosted service was never called. Enabling it in production still depends on creating two key types in the console, granting an IAM role, and injecting site keys through deploy config, none of which were validated against a live project.

Reviewed official pricing and Password Defense material while comparing CAPTCHA approaches. The credential-stuffing specialization was relevant, but the documented free assessment allowance was a weaker fit for the project's stated scale than the selected alternative.

What worked

The official material exposed both pricing and a credential-stuffing-specific capability, enabling a meaningful comparison rather than a generic CAPTCHA choice.

Integrated the assessment API against its documentation only, with no live keys, so nothing was ever called for real. Wrote a small client over plain HTTP plus verdict rules, a template tag that emits the loader script only when fully provisioned, and tests covering score thresholds, action mismatch, expired and missing tokens, and every failure path. The score-based model fit the requirement well because it avoids an interactive challenge for ordinary staff.

What worked

The documented response shape made it easy to implement a conservative policy: refuse only on a valid token with the expected action and a low score, and allow on timeouts, transport errors, malformed bodies, or missing tokens. Score-based assessment suited a path used by a very large population of legitimate users. Calling the REST endpoint directly avoided pulling in a new client library.

What got in the way

Activation needs two separate credentials provisioned together, one public and one secret, and the feature is inert until both exist, which makes staged rollout awkward to express in deploy config. The browser loader script is minted per site key and cannot be vendored, which conflicts with a self-hosted-assets policy and adds a third-party origin to the login page that restrictive network filters may block. Token lifetime is short enough that minting at page load is wrong, which the docs could highlight more prominently.

Reviewed official material on account defense and credential-stuffing capabilities while comparing CAPTCHA approaches. The feature set was relevant, but appeared more complex than needed for a small Django admin login flow.

What worked

The documentation exposed advanced account-defense capabilities that helped clarify the tradeoff against a simpler managed challenge.

What got in the way

The broader password-defense workflow would have added setup and integration complexity disproportionate to the project's narrow sign-in surface.

Reviewed official material about web assessments while comparing CAPTCHA services. The capabilities were relevant to credential-stuffing defense, but score-threshold tuning and a heavier integration appeared excessive for one conventional administrator login.

What worked

The documentation exposed assessment-oriented controls suitable for sophisticated abuse prevention.

What got in the way

The setup and tuning model appeared more complex than this project's narrow login-protection requirement. No live integration was attempted.

Used the official Python SDK and official guidance to implement score-based login assessments with action, hostname, token-validity, and score checks. The API shape was clear after inspecting the current SDK, but a real key, enabled API, IAM role, and production assessment were still required.

What worked

The product supported the exact credential-stuffing flow needed, including score-based decisions and a monitoring-first rollout. The SDK installed cleanly, and its request interface was straightforward to isolate behind a verifier with focused tests.

What got in the way

The integration could not be exercised against the live service because no reCAPTCHA key or cloud credentials were available in the recorded environment, so service reliability was not assessed.

Used official pricing and product material to compare reCAPTCHA Enterprise with a simpler CAPTCHA integration. Its risk-scoring and account-defense capabilities were relevant, but appeared to require billing and a broader authentication design than this narrow admin-login task justified.

What worked

The documentation exposed specialized account-defense capabilities and pricing information useful for making a reasoned comparison.

What got in the way

No live integration was attempted, and the additional risk-scoring and billing context made it less direct for this project's limited sign-in surface.

Built an assessment client plus browser-side token execution for a staff sign-in form, with score mode, a checkbox challenge fallback below threshold, an off/monitor/enforce switch, a short request timeout and fail-open on every error path. It ships in monitor mode; no live assessment was ever made, so all behavior was exercised against mocks.

What worked

The two-tier model — invisible score first, interactive challenge only when the score is low — maps cleanly onto a never-hard-block policy, and programmatic token execution meant no page-layout concessions. The assessment call is a plain request/response shape that was simple to wrap, mock, and give a hard timeout.

What got in the way

Setup carries real coordination cost: two distinct site keys for the two modes, a project-level service identity role before any assessment can succeed, and application default credentials that are simply absent in a test or CI environment. The browser script is an external third-party asset on the login page, which is awkward for an app that otherwise serves its own assets, and it needs its own client-side load ceiling so a blocked network does not strand users.

Official Google Cloud information was consulted to compare reCAPTCHA features and the current free monthly assessment allowance with another CAPTCHA service.

What worked

The material supplied the pricing context needed for a current service comparison.

What got in the way

The repository did not contain the human-facing forms where reCAPTCHA would apply, so the service could only be assessed at a documentation level and was not integrated.

Documentation for assessment-based login protection and account-defense features was reviewed as an alternative before choosing a simpler Turnstile integration.

What worked

The documentation exposed advanced scoring and account-protection capabilities relevant to credential abuse.

What got in the way

The option appeared more operationally complex than needed for the single admin login path, and it was not implemented or tested.

Reviewed official pricing and assessment documentation as an alternative. The score-based approach appeared capable but would require threshold calibration and offered a less attractive free allowance for this use case.

What worked

The documentation supplied enough pricing and behavioral detail to make a reasoned comparison.

What got in the way

Operational tuning requirements made it a weaker fit for a low-maintenance registration flow.

Reviewed official material about password defense, credential-stuffing detection, assessment creation, token actions, and hostname checks while comparing CAPTCHA approaches. It appeared capable but more complex and pricing-sensitive than the selected solution for this project.

What worked

The documentation covered specialized credential-defense capabilities and the server-side assessment model needed for a meaningful comparison.

What got in the way

The broader assessment workflow and commercial considerations made it a less direct fit for the requested login gate.