网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载本指南讲解 Cap 开源验证码项目中cap.js/solver的完整用法这是一个零依赖、单文件的服务端求解库专为机器对机器M2M流程设计只能运行在 Bun 上。读完本文你将掌握如何在服务端从种子seed或质询列表直接求解 Cap 的工作量证明proof-of-work质询、理解其底层求解算法以及如何把求解结果提交给 Cap 服务端完成验证与换取通行令牌。什么是 cap.js/solvercap.js/solver是 Cap 提供的一个独立standalone库用于在服务端求解 Cap 质询challenge。与面向浏览器的 widget 相比它同样快速高效但实现上极度简单——零依赖、单文件且有一个硬性前提只能在 Bun 运行时下使用。需要特别强调两点边界它不会绕过任何实际的工作量证明。solver 老老实实地完成质询所要求的计算只是把原本在浏览器 widget 里完成的求解过程搬到了服务端因此它产出的是真实、可被服务端验证的合法解。它不支持 instrumentation 质询。Cap 有两种质询类型proof-of-work工作量证明和 instrumentation浏览器行为探针。instrumentation 质询依赖浏览器环境的运行特征详见 instrumentation 指南服务端没有浏览器环境因此cap.js/solver只覆盖 proof-of-work 类质询。从仓库源码看Cap 的 proof-of-work 质询共包含三种协议均可在服务端被求解协议原理相关实现sha256-pow寻找 noncen使SHA-256(salt n)的十六进制结果以target前缀开头core/src/crypto.js、core/test/helpers.jshashwx基于 WASM 的专用哈希函数寻找满足hash U64_MAX / difficulty的 noncecore/src/hashwx.js、widget/src/src/worker.jsrsw基于 RSA 的重复平方repeated squaring计算y x^(2^t) mod Ncore/src/rsw.js安装solver以 npm 包形式发布通过 Bun 的包管理器安装bun add cap.js/solver由于库只在 Bun 上运行请确保你的服务端环境已经安装 Bun。安装完成后即可在 Bun 脚本中直接import使用。用法一从种子seeded质询求解服务端最典型的场景是你已经通过 Cap 的generateChallenge拿到了一个 JWT 形式的质询令牌token其中携带了质询数量c、盐长度s与难度d等参数。此时可以把 token 直接交给 solver并显式传入这些参数import solver from cap.js/solver; console.log( await solver(challenge token, { c: 50, // 质询数量 s: 32, // 盐的长度字节/十六进制字符数 d: 4, // 难度 }), );solver会基于该 token 派生出c组 salt/target并逐一求出满足条件的 nonce最终返回一个数组[67302, 64511, 40440, 27959, 71259 /* ... */]种子派生逻辑的源码依据token 的种子派生在仓库中有明确实现。capjs-core通过 FNV-1a 哈希与自实现 PRNG 从 token 派生 salt 与 target——prng(token i, s)生成第 i 个质询的盐prng(token i d, d)生成其目标前缀然后循环递增 nonce直到SHA-256(salt nonce)以 target 开头见 core/src/prng.js 与 core/test/helpers.js。服务端求解器执行的正是这套算法因此其结果与服务端验证逻辑完全一致。参数的默认值与取值范围solver 的种子参数与服务端generateChallenge的默认值一一对应。仓库中 core/src/index.js 定义c质询数量默认50合法范围1 ~ 1000s盐长度默认32合法范围1 ~ 256d难度即 target 前缀的十六进制位数默认4合法范围1 ~ 16。难度d每增加 1平均需要多计算约 16 倍哈希因此在实际 M2M 场景中应结合自身服务端 CPU 能力与对延迟的容忍度选择合适的难度。用法二从质询列表求解如果服务端不希望维护种子派生这层间接关系也可以直接传入显式的质询列表。列表中每一项是一个二元组第一项为盐salt第二项为难度前缀targetimport solver from cap.js/solver; const challenges [ [a5b6fda4aaed97cf61d7dd9259f733b5, d455], [286bcc39249f9ee698314b600c32e40f, f0ff], [501350aa7c46573cb604284554045703, 4971], [a55c02f3b9b4cd088a5a7ee3d4941c14, eab7], [5f3362c12e2779f56f4ef75b4494f5e6, 999f], /* ... */ ]; console.log(await solver(challenges));输出同样是一个与输入顺序对应的 nonce 数组[67302, 64511, 40440, 27959, 71259 /* ... */]这种形式对应 Cap format-2 质询中的sha256-pow协议服务端生成的每个质询载荷都包含{ salt, target }客户端只需寻找 nonce 使SHA-256(salt nonce)以target开头生成与验证逻辑见 core/src/index.js 与 core/src/index.js。提示hashwx与rsw协议同样属于 proof-of-work。从 core/src/index.js 的实现看rsw质询的载荷为{ N, x, t }模数、基值与迭代次数hashwx质询的载荷为{ c, d, n }挑战、难度、每哈希 nonce 数。这些质询同样可以在服务端被求解只是求解方式与参数形态不同。第二个参数选项详解await solver(challenges, options)的第二个参数是可选的且始终是一个对象。无论传不传、传多少workerCount与onProgress对所有质询类型都生效c/s/d仅对基于种子的质询有意义。workerCount作用范围所有质询类型。含义求解时使用的 worker 数量。默认值CPU 核心数即navigator.hardwareConcurrency。worker 划分逻辑在仓库的 widget worker 中可以看到同样模式每个 worker 从自己的起始区块开始按步长workerCount推进搜索空间见 widget/src/src/worker.js。在服务端更高的workerCount可以更充分地利用多核 CPU但也会占用更多内存与 CPU 时间需要根据机器的核心数与同时处理的请求量做权衡。onProgress作用范围所有质询类型。含义进度更新回调。进度回调的典型形态可以参考 widget 端的实现worker 每完成一定量哈希就上报一次进度widget 中为每约 150ms 上报一次见 widget/src/src/worker.js。在 M2M 场景中onProgress常用于日志记录、超时判断或给调用方返回阶段性状态await solver(challenges, { workerCount: 4, onProgress: (progress) { console.log(solving... ${progress}); }, });c/s/d仅限种子质询作用范围仅基于种子的质询。含义指定要生成的解的数量c、质询盐的大小s与难度d。当第一个参数是字符串 token 时solver 需要这三个参数才能确定要生成多少组 salt/target、以多大强度求解当第一个参数是显式质询列表时这些信息已经包含在列表中无需也不应再传。完整的 M2M 集成流程把上面的知识串起来一个典型的服务端 M2M 流程如下获取质询调用 Cap 实例的POST /site-key/challenge接口或通过capjs-core的generateChallenge在本地生成拿到携带质询参数、带有过期时间的 JWT token生成逻辑见 standalone/src/cap.js。服务端求解把 token 或显式质询列表交给cap.js/solver得到 nonce 数组。提交验证将{ token, solutions: [nonce, ...] }POST 到 Cap 实例的POST /site-key/redeem接口。服务端会校验每个 nonce 对应的哈希是否满足 target 前缀条件、token 是否过期、是否已被兑换nonce 一次性消费验证通过后返回一个带 TTL 的兑换令牌见 standalone/src/cap.js 与 core/src/index.js。这套流程让没有浏览器环境的服务端程序如批量数据抓取、自动化测试、CI 流水线、服务间调用也能正常通过 Cap 的验证同时保持与浏览器 widget 相同的求解效率。边界与注意事项仅限 Buncap.js/solver依赖 Bun 的运行时能力不能在 Node.js 或 Deno 下使用。只覆盖 proof-of-work如果目标站点配置了 instrumentation 质询solver 无法求解需配合真实浏览器环境如 Cap 的前端 widget 或 programmatic 模式见 programmatic 模式指南。不绕过工作量证明求解计算是真实的、可验证的不要指望通过它跳过验证——服务端会逐一校验解的正确性。注意默认参数种子模式下c50, s32, d4是常见默认组合难度越高单次求解耗 CPU 越多请为服务端预留足够的计算资源仓库中的 core/test/benchmark.js 展示了不同参数组合下generateChallenge/validateChallenge的基准测试方式可用于评估容量。延伸阅读Cap 核心库说明capjs-core的质询生成与验证 API。hashwx 协议指南hashwx 质询的难度、nonce 与验证细节。instrumentation 指南solver 不支持的另一种质询类型。Standalone 部署指南如何自托管 Cap 实例并提供/challenge与/redeem接口。编程式集成指南在客户端 JS 中通过new Cap()编程式求解适用于浏览器环境。赞分享网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载相关推荐使用 cap.js/solver 在 Bun 服务端求解 Cap 的 Proof-of-Work ChallengeM2M 场景指南使用 cap.js/solver 在 Bun 服务端求解 Cap 的 Proof of Work ChallengeM2M 场景指南 cap.js/so网络安全应用安全后端Cap 服务端 M2M 集成指南用 cap.js/solver 在 Bun 中离线求解 Proof-of-Work 挑战Cap 服务端 M2M 集成指南用 cap.js/solver 在 Bun 中离线求解 Proof of Work 挑战 cap.js/solver 是网络安全应用安全后端在 Bun 服务端用 cap.js/solver 求解 Cap PoW 挑战M2M 机器对机器集成指南在 Bun 服务端用 cap.js/solver 求解 Cap PoW 挑战M2M 机器对机器集成指南 本篇指南以 docs/de/guide/solver网络安全应用安全后端上一篇多平台直播分发神器OBS同步推流插件完全指南下一篇终极指南WhateverGreen与其他kexts的协同工作构建稳定显卡驱动环境创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考