ALTCHA

I installed the widget package and placed it on the sign-in form so the browser can solve a proof-of-work challenge and post the proof with the credentials. Widget integration docs were not enough: the bundle reads the DOM at import time, so it had to load after mount, and the submit interceptor, payload field, and checkbox rules only became clear from the source. Documented difficulty settings were slow enough that I lowered them. The rendered page included the widget and challenge URL, and the production build bundled the script with the app. I never clicked the widget in a browser.

What worked

The widget ships with its own worker, English strings, and a configuration attribute for hiding the footer and logo, so the sign-in page can load it from the app bundle. After a dynamic import on mount, the server-rendered form included the widget element, the challenge URL, and a payload field.

What got in the way

A normal server import is unsafe because the module reads window and document while loading. Form association was hard to trust from the docs: I had to trace the bundle to see that the payload input is a light-DOM field, and auto-submit raced with the page submit handler. The published cost and counter range took several seconds when timed with the server library, which is too slow for sign-in. The interactive worker path stayed untested.

Installed altcha 3.2.3 via npm and used createChallenge, verifySolution and solveChallenge from altcha/lib on the server to create and verify a self-hosted proof-of-work challenge for the login form. Integrated widget via import 'altcha' in Svelte.

What worked

Self-hosted, no external verification endpoint, small bundle and HMAC-based verification fit single-machine SQLite constraints. Once correct parameters were found, challenge creation and verification were reliable and testable with in-memory replay protection.

What got in the way

Documentation for server options was fragmented across site, GitHub README and inline types. Required trial and error to discover correct combination of algorithm, deriveKey, hmacSignatureSecret, cost and expiresAt; initial attempts failed silently.

Evaluated both the server library and widget via registry metadata, tarball unpacking and doc fetches. Documentation described HMAC challenge flow clearly but widget bundle size prompted a lightweight custom client implementation using pure Node crypto on the server.

What worked

Server API for challenge creation and verification was clear and MIT-licensed; docs explained algorithm, expiry handling and HMAC usage well enough to reimplement with built-in crypto.

What got in the way

Widget distribution was heavier than desired for the minimal setup, and examples assumed the full widget; required translating the protocol to a custom minimal implementation.

Installed the widget package, mapped React types and attributes from the starter and type defs, and dynamically loaded it on the client so a no-JS server render would not crash.

What worked

Types and a production build succeeded. The widget landed as its own client chunk, and the documented form field name matched what the action verified.

What got in the way

There was no first-party Remix integration, so custom-element SSR and attribute coverage had to be inferred. The live checkbox was never exercised in a browser, so widget UX was unconfirmed.

Installed altcha-lib to issue HMAC-signed challenges and verify solutions inside a SvelteKit login action before any password work. Official docs and the framework helper were incomplete around request-body consumption and some key helpers, so a thin wrapper around the core API was used instead. Challenge issue, verify, and replay rejection all worked after the default cost was lowered.

What worked

The core challenge and verify APIs were enough for a self-hosted flow with an in-memory one-time store. A solved token reached the existing invalid-credentials path, and replaying the same token was rejected. The solver API was usable from a small Node script for end-to-end checks.

What got in the way

The SvelteKit helper reads the request body in a way that blocks a later form parse. A helper for deriving the HMAC key was not on the main export. Default proof-of-work cost made a login solve take far too long. Example starter files fetched from the public docs returned 404, and a random-integer helper uses a surprising argument order.

Installed the server library, read v2 challenge and verify docs, then issued PBKDF2 challenges, solved them locally, and verified payloads in the booking action with in-memory replay protection.

What worked

createChallenge, solveChallenge, and verifySolution completed a full round-trip. HTTP tests rejected missing and reused payloads and accepted a freshly solved challenge before any booking work.

What got in the way

Widget versus library version pairing was not obvious from one page. The main package did not export the HMAC helper used in framework samples, so verification had to be written against core APIs and a custom payload parser.

Installed the widget package, loaded it only in the browser, and put the web component on each booking form so a proof-of-work token is posted with the request. Official guides covered React and Next more than this stack, and custom-element types plus client-only import needed extra care. Once wired, unsolved posts were rejected and a solved widget still completed a booking.

What worked

The checkbox-style widget and challenge URL fit a native POST form without a vendor account, cookies, or an outbound verify call. Client-only loading kept the server bundle clean, and production build included the widget as expected.

What got in the way

There was no first-party helper for this framework, so widget attributes, TypeScript declarations, and hydration had to be pieced together from React starters and type files. Docs mixed older and newer APIs, which slowed setup.

Installed the server library and used its challenge, verify, and solver APIs for a resource route, action check, replay store, and a local roundtrip test. Core functions were enough without a framework plugin. Docs and examples split v1 and v2 shapes, so payload parsing and HMAC setup took extra source reading before verification behaved correctly.

What worked

createChallenge, verifySolution, solveChallenge, and the capped in-memory store covered issue, check, and replay rejection. A scripted roundtrip passed, missing payloads failed closed, and a solved payload still created a booking.

What got in the way

No plugin existed for this framework, public examples disagreed on payload shape, and one documented source path was missing. HMAC handling had to be delayed until runtime so a build would not write a secret the deploy image would not have. Default puzzle time felt slow in testing.

Installed the ALTCHA web-component widget on a Svelte 4 login form so the browser fetches and solves a self-hosted proof-of-work challenge before submit. Setup needed a configuration JSON attribute, custom-element handling, and care around Svelte 5-oriented types. A production build bundled the widget; the live widget was never clicked in a browser.

What worked

The widget dropped into the existing form as a custom element and appeared in the rendered login HTML. Hide-footer and theme options were available through a configuration object, and the production client bundle included the widget and its worker.

What got in the way

Docs and types lean toward a newer Svelte major than this app, so custom-element attributes and type imports needed extra checking. Widget CSS variables had recently changed. Browser interaction with the widget was not observed.

Installed the widget and server library, issued challenges from the app, verified solutions in the login action before password hashing, and blocked replays with an in-memory map. Core APIs worked after reading installed types; official site guides and the framework helper were a poor fit.

What worked

createChallenge, solve, verify, and one-time nonce checks succeeded in local roundtrips. Installed type definitions were enough to wire a thin helper. The widget payload shape matched server parsing, and missing or invalid payloads were rejected before password work.

What got in the way

Official website integration pages returned not found, and some public example sources were missing. The bundled framework helper reads the request body, which would have blocked the form action, so it was skipped. v1 versus v2 and export paths took extra hunting.

Used the Python solver and challenge helpers to automate login tests: parse the embedded challenge, solve it, and submit the payload. Also read the library to confirm verification and replay behavior.

What worked

solve_challenge produced payloads the Django field accepted. Once remote static calls were removed from tests, solving was fast enough that the suite completed cleanly.

What got in the way

A slow failing run was first blamed on default proof-of-work difficulty; that delay came from unrelated credential timeouts, not from the solver itself.

Installed the server library, read its SvelteKit plugin source and types, then issued PBKDF2 challenges and verified proofs on the login action before password hashing. In-process replay protection worked on a single-process app. Official site pages 404ed, so setup followed GitHub docs and type declarations instead.

What worked

Challenge creation, solving, verification, and replay rejection all behaved as expected once verification used the extracted form field. The library was a good match for a self-hosted, no-queue setup and kept bot traffic off expensive password hashing.

What got in the way

The documented SvelteKit helper reads the request body, which blocked a later read of the same login form. Website integration pages and a starter example returned 404 or timed out. Calling verify needed a thin wrapper because the plugin helper was unsafe for this form action.

Installed the client widget, placed it on the sign-in form, and configured auto-solve on submit with quiet theming. Website integration docs 404'd, and the v3 widget had to be paired with a v2 server library. A production build showed the widget in the client bundle; the live form was never exercised in a browser.

What worked

The package installed cleanly. Importing the widget stayed SSR-safe because custom-element registration is window-guarded. Auto-on-submit kept the form a normal POST, and the hidden field payload matched the server verifier's expected base64 JSON shape.

What got in the way

Official website-integration docs were missing. Widget attributes are a short allowlist, so hiding branding and setting theme details had to go through a configuration string. Runtime click-through of the widget was not observed in this environment.

Installed the widget package and mounted it on the sign-in form with auto-solve on submit pointing at a local challenge route. Production build included the widget on that page only. Browser click-through was not available, so the widget’s live solve path was not observed.

What worked

The custom element showed up in server-rendered login HTML, and the production client bundle for that page included the widget at a modest size. Dynamic import on mount avoided running the web component during server render.

What got in the way

Public widget docs were missing or timed out. Server-side import looked unsafe under SSR, so the component had to be loaded on the client. Live checkbox or auto-submit behavior in a real browser was never confirmed.

Used the Python library to create and solve v1 challenges in tests, and vendored the minified widget next to other first-party static files. The installed 1.0.0 API worked with the Django wrapper, but the current GitHub README and newer npm widget described incompatible APIs, so the published package—not the latest docs—had to be the source of truth.

What worked

Challenge creation, solving, and HMAC verification in 1.0.0 were straightforward once read from the installed module. The bundled widget could be copied into first-party static files and auto-solved on the login form.

What got in the way

The main-branch Python README documented a newer API than the 1.0.0 release. Fetching a current npm widget would have broken the Django 1.0.0 integration, which still expects the v1 challenge format.

Installed the server library, issued signed challenges from a public GET handler, and verified payloads in the login action before password checks, with an in-memory map for replay protection. Classic v1 helpers looked simpler at first, but the current widget needed the v2 challenge format. The official app-framework helper was skipped because it reads the request body, which would have broken the existing form parser. Challenge minting, solving, verification, and replay rejection all worked in live request tests.

What worked

Challenge creation, HMAC verification, and replay blocking behaved as expected once wired by hand. A solver helper in the same package was enough to prove a good payload reached password failure rather than captcha failure, and a reused payload was rejected.

What got in the way

Public integration docs returned not found, so setup depended on registry pages and repository files. HMAC key derivation lived on a nested framework export, not the main entry. The framework helper consumes the request body, so it could not sit in front of an action that already reads form fields. Solving a default-cost challenge took several seconds.

Installed the widget package and dropped the custom element onto the login form so the browser would fetch a signed proof-of-work challenge and post the payload with the credentials. Widget docs and types assumed a newer UI compiler than this app used, so the element had to be declared by hand and HTML attributes kept lowercase. Auto-solve timing was tuned after a multi-second proof-of-work delay. The control was confirmed present in server-rendered HTML, not by clicking it in a browser.

What worked

The custom element was straightforward to place on an existing form, exposed theming hooks that matched the surrounding fields, and could start work on load so submit was not blocked on a long puzzle.

What got in the way

The bundled UI types targeted a newer compiler than the project, so the official type entry could not be used. Official site integration docs were missing, and default puzzle cost made automatic solving slow enough that the load-time attribute had to be reconsidered.

Used the core Python library alongside the Django package to understand challenge and payload helpers and to mint signed test solutions. Verification followed HMAC rather than server-side cost, which made low-cost test challenges valid and simplified CI payloads.

What worked

Challenge creation and payload encoding were predictable once the v2 helpers were inspected, and signed test payloads verified cleanly in the Django tests.

Installed the official Django integration, read its settings, widget, testing, and verification docs, then added an admin login field with inline challenges, vendored widget media, test mode, and cache-backed replay protection. Mixin constructor behavior versus AuthenticationForm needed a careful read; tests covering valid login, rejection, and replay then passed.

What worked

Inline challenges avoided extra public URLs. Bundled widget JavaScript fit a no-CDN static pipeline. Test mode and field-level verification blocked stuffing before password checks. Form media hooked into the admin login template.

What got in the way

Docs are split across several pages, so wiring HMAC, cache, widget options, and admin login took extra reading. Loc-mem cache produced a replay-protection system check. Mixin request handling had to be checked against Django's login form constructor.

Installed the widget and server library and put a self-hosted proof-of-work check on the public login POST. Docs mixed v1 and v2, and the official framework plugin was too heavy for a single form field, so I used the lower-level challenge and verify helpers with an in-memory replay map. HTTP checks showed missing tokens rejected, solved tokens reaching the password check, and replays blocked.

What worked

Challenge creation, solving, HMAC verification, and nonce replay blocking all matched expectations in round-trip scripts and live requests. Leaving verification off when the HMAC secret is unset was straightforward. The widget rendered on the login page and posted a hidden field the server could read.

What got in the way

Docs and the official SvelteKit plugin pushed a cookie-oriented v2 flow that did not fit a simple form action. A helper I needed was not on the main export, the published randomInt argument order looked reversed, and the npm package page timed out, so I had to read type declarations and source to wire PBKDF2 correctly. Widget click-through was not exercised in a browser.

Used the server library to issue HMAC-signed proof-of-work challenges, verify the login field, and reject replays in memory. The SvelteKit helper was skipped because verifying via the request event consumes the body. Isolated create-solve-verify-replay checks against the library passed.

What worked

Challenge creation, solving, and verification worked together in a Node round-trip. Replay, garbage input, and missing fields failed as expected. No extra cache or queue was required for a single-process app.

What got in the way

Docs mixed v2 server and v3 widget APIs. HMAC key derivation was not on the main export and lived on a framework subpath. The SvelteKit event verifier cannot run after form data is already read. Helper argument order is easy to get wrong.