网络安全应用安全后端【免费下载链接】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点击查看免费下载本文是一份面向 Node.js / Bun 开发者的实战指南讲解如何通过官方中间件cap.js/checkpoint-express为 Express 应用接入 Cap Checkpoint——一种复刻 Cloudflare 浏览器检查过渡页的自托管、开源防护方案。文中会覆盖安装命令、完整的中间件接入代码、全部配置选项的语义解析以及质询令牌如何在后端完成校验的完整链路。读完本文你将能够在一个 Express 应用中独立部署并验证这套工作量证明Proof-of-WorkCAPTCHA 与浏览器环境检查机制。Cap Checkpoint一种“核弹级”的入口防护方案在接入 Express 之前先理解 Checkpoint 在整个 Cap 体系中的定位。根据 Cap 官方文档 docs/zh/guide/middleware/index.md 的说明Cap Checkpoint此前称为中间件用于复刻 Cloudflare 的浏览器检查过渡页在机器人、LLM 与自动化滥用到达你的网站之前就将其拦截。它有几个鲜明的特点部署成本低只需在服务器上添加几行代码无需把整个网站迁移到 Cloudflare拦截能力强它属于“核弹级”方案因为除了恶意机器人之外它也会影响搜索引擎爬虫等善意的机器人接入前需要评估你的业务对爬虫流量的依赖防护类型工作量证明Proof-of-WorkCAPTCHA 浏览器环境检查instrumentation后者可显著提高机器人的作弊门槛。Cap 生态为多种服务端框架提供了同构的官方中间件包Express 对应的是cap.js/checkpoint-express此外还有 Honocap.js/checkpoint-hono见 docs/zh/guide/middleware/hono.md与 Elysiacap.js/middleware-elysia见 docs/zh/guide/middleware/elysia.md。它们共享同一套参数设计本文对配置选项的讲解同样适用于其他框架。安装依赖在项目目录下运行bun add express cookie-parser cap.js/checkpoint-express这条命令会安装三个包包名作用expressWeb 服务端框架提供路由与中间件体系cookie-parser解析请求中的 CookieCheckpoint 中间件依赖 Cookie 来跟踪质询通过状态cap.js/checkpoint-expressCap Checkpoint 的 Express 官方中间件说明文档给出的包管理器是Bun仓库整体也基于 Bun 生态构建例如 core/package.json 与 standalone/package.json 均使用 Bun 管理。如果你使用 npm / pnpm请自行替换为对应的npm i/pnpm i命令。快速开始为 Express 应用接入 Checkpoint以下是从官方文档 docs/zh/guide/middleware/express.md 继承的完整示例。它演示了如何用中间件保护全部路由只有通过质询的客户端才能继续访问受保护内容import express from express; import cookieParser from cookie-parser; import path from path; import { dirname } from path; import { fileURLToPath } from url; import { capCheckpoint } from cap.js/checkpoint-express; const app express(); const __dirname dirname(fileURLToPath(import.meta.url)); app.use(express.json()); app.use(cookieParser()); app.use( capCheckpoint({ /* token_validity_hours: 32, tokens_store_path: .data/tokensList.json, token_size: 16, verification_template_path: join(__dirname, ./index.html), */ }), ); app.get(/, (req, res) { res.sendFile(path.join(__dirname, success.html)); }); app.listen(3000, () { console.log(Server running on http://localhost:3000); });代码要点cookieParser()必须在capCheckpoint(...)之前注册因为质询通过后的令牌状态依赖 Cookie 传递capCheckpoint({...})以全局中间件形式挂载因此会拦截其之后注册的全部路由——示例中/路由返回的success.html只有通过质询的客户端才能看到示例中的配置对象全部处于注释状态此时使用默认配置即可直接运行。就是这么简单。运行后打开http://localhost:3000未通过质询的访问会被引导到浏览器检查过渡页完成工作量证明与浏览器环境检查后才会看到你的真实页面。配置选项详解示例注释中展示的四个选项是这套中间件的核心参数其语义可由官方文档与仓库内其他框架文档docs/zh/guide/middleware/hono.md、docs/zh/guide/middleware/elysia.md交叉印证选项类型/默认值含义token_validity_hours小时数默认 32质询通过后颁发的令牌有效时长。超过此时长后客户端需要重新完成质询tokens_store_path文件路径如.data/tokensList.json令牌存储位置。Checkpoint 中间件在本地文件系统中记录已颁发/待校验的令牌token_size字节数默认 16令牌的大小字节影响令牌熵值与不可预测性verification_template_pathHTML 文件路径浏览器检查过渡页的模板文件即质询页面的 HTML完整启用全部自定义配置的写法如下import { join } from path; app.use( capCheckpoint({ token_validity_hours: 32, // 令牌有效时长小时 tokens_store_path: .data/tokensList.json, // 令牌列表存储文件 token_size: 16, // 令牌大小字节 verification_template_path: join(__dirname, ./index.html), // 质询过渡页模板 }), );验证模板与/__cap_clearanceverification_template_path指向的 HTML 模板是 Checkpoint 的核心 UI。从 docs/zh/guide/middleware/elysia.md 的说明可以确认模板中只需包含一个指向/__cap_clearanceURL 的验证组件cap-widget或隐藏求解器Checkpoint 中间件会在该 URL 上完成质询的签发、校验与放行逻辑。也就是说你不需要在模板里手写任何质询协议逻辑只需要引入 Cap 验证组件Widget的脚本在模板中放置一个cap-widget元素或隐藏求解器让验证组件指向/__cap_clearance中间件会自动接管后续流程。验证组件Widget的完整用法可参考 docs/zh/guide/widget.md。令牌如何被校验从质询通过到放行要真正理解这套中间件的安全性需要知道质询通过之后发生了什么。Cap 生态的校验链路在服务端源码中有清晰的实现以 standalone/src/siteverify.js 为例cap.js/checkpoint-express与 Cap Standalone 后端共享相同的令牌校验语义可以归纳出以下关键环节1. 令牌格式。站点验证时response客户端提交的令牌必须能被:分隔成三段见 standalone/src/siteverify.js第一段是站点密钥。格式不合法会直接返回400。2. 站点密钥与秘密密钥校验。服务端根据站点密钥查找对应的secretHash哈希存储不保存明文通过 standalone/src/secret-hash.js 中的verifySecret校验提交的secret不匹配返回403。3. 令牌的一次性消费与过期。服务端使用GETDEL语义standalone/src/siteverify.js读取并删除令牌令牌必须存在否则404、必须未过期否则403并且每个令牌只能被成功验证一次防止重放攻击。4. 成功响应。全部校验通过后返回{ success: true }。因此无论使用哪个接入方式Checkpoint 中间件或直接对接 Standalone你的后端都永远不要信任客户端传来的未经验证的令牌——必须先经过上述校验流程才能认为该请求来自已通过质询的真实浏览器。与 Cap Standalone 后端配合完整的生产部署形态cap.js/checkpoint-express解决的是“入口拦截”这一层而质询本身的签发、令牌的最终校验则依赖一个 Cap 服务端。官方推荐的部署方式是Cap Standalone详见 docs/zh/guide/standalone/index.md它运行在 Bun 上空闲内存占用约 50 MB内置 instrumentation浏览器环境检测质询并提供兼容 reCAPTCHA 的siteverifyAPI 与一个管理站点密钥的 Web 控制台推荐用 Docker Compose 一键启动镜像tiago2/cap:latest搭配 Valkey/Redis 存储随后在控制台创建站点密钥记下站点密钥site key与秘密密钥secret key客户端验证组件通过data-cap-api-endpointhttps://instance_url/site_key/指向你的实例docs/zh/guide/standalone/index.md用户完成 CAPTCHA 后后端向instance_url/site_key/siteverify发送POST { secret: ..., response: ... }验证令牌docs/zh/guide/standalone/index.md。在生产环境中将 Checkpoint 的验证模板指向你的 Standalone 实例即可形成完整闭环Express 入口拦截 → 质询过渡页 → Cap Standalone 签发与校验 → 放行受保护路由。部署时还需注意Standalone 实例必须能从公网访问验证组件才能与它通信如果部署在反向代理后面请按 docs/zh/guide/standalone/options.md 中的说明配置速率限制与客户端 IP 识别X-Forwarded-For/X-Real-IP等头/siteverify端点默认不做速率限制因为它面向服务器间调用docs/zh/guide/standalone/options.md。注意事项与适用前提环境要求官方文档以 Bun 为包管理器与运行环境仓库整体基于 Bun 构建建议在 Bun 运行时下使用以获得与文档一致的行为。影响搜索引擎爬虫如前文所述Checkpoint 会拦截所有未通过质询的客户端包括善意爬虫。如果 SEO 对你的业务至关重要需要谨慎评估或只在敏感路由上启用。默认配置即可运行不传任何配置时中间件使用内置默认值令牌有效期 32 小时、令牌大小 16 字节、默认存储路径适合快速验证正式上线前再显式配置verification_template_path与持久化路径。小结接入 Cap Checkpoint 到 Express 只需要三步安装cap.js/checkpoint-express、在cookieParser之后挂载capCheckpoint中间件、准备一个指向/__cap_clearance的验证模板。再结合 Cap Standalone 完成质询签发与siteverify校验你就在完全自托管、开源的条件下为自己的 Express 应用建立了一道复刻 Cloudflare 风格的浏览器检查防线——不依赖任何第三方闭源验证码服务。赞分享网络安全应用安全后端【免费下载链接】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点击查看免费下载相关推荐在 Express 中集成 Cap Checkpoint用 cap.js/checkpoint-express 为路由加上自托管的工作量证明 CAPTCHA 防线在 Express 中集成 Cap Checkpoint用 cap.js/checkpoint express 为路由加上自托管的工作量证明 CAPTCHA网络安全应用安全后端Cap Express Checkpoint 接入指南用 cap.js/checkpoint-express 为路由加装自托管工作量证明验证Cap Express Checkpoint 接入指南用 cap.js/checkpoint express 为路由加装自托管工作量证明验证 本指南讲解如何网络安全应用安全后端OMI macOS 桌面端 SwiftUI/AppKit 运行时调试手册从第一个不可能转变到持久化防护OMI macOS 桌面端 SwiftUI/AppKit 运行时调试手册从第一个不可能转变到持久化防护 导读 当 macOS UI 故障的可见表象无法直网络安全应用安全后端上一篇WTF-Solidity 实战用 Solidity 从零搭建零手续费去中心化 NFT 交易所 NFTSwap下一篇ReactXP VirtualListView 深度指南跨平台虚拟化列表的实现原理与性能优化实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为 Express 添加 Cap Checkpoint：使用 @cap.js/checkpoint-express 以自托管工作量证明 CAPTCHA 保护路由
网络安全应用安全后端【免费下载链接】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点击查看免费下载本文是一份面向 Node.js / Bun 开发者的实战指南讲解如何通过官方中间件cap.js/checkpoint-express为 Express 应用接入 Cap Checkpoint——一种复刻 Cloudflare 浏览器检查过渡页的自托管、开源防护方案。文中会覆盖安装命令、完整的中间件接入代码、全部配置选项的语义解析以及质询令牌如何在后端完成校验的完整链路。读完本文你将能够在一个 Express 应用中独立部署并验证这套工作量证明Proof-of-WorkCAPTCHA 与浏览器环境检查机制。Cap Checkpoint一种“核弹级”的入口防护方案在接入 Express 之前先理解 Checkpoint 在整个 Cap 体系中的定位。根据 Cap 官方文档 docs/zh/guide/middleware/index.md 的说明Cap Checkpoint此前称为中间件用于复刻 Cloudflare 的浏览器检查过渡页在机器人、LLM 与自动化滥用到达你的网站之前就将其拦截。它有几个鲜明的特点部署成本低只需在服务器上添加几行代码无需把整个网站迁移到 Cloudflare拦截能力强它属于“核弹级”方案因为除了恶意机器人之外它也会影响搜索引擎爬虫等善意的机器人接入前需要评估你的业务对爬虫流量的依赖防护类型工作量证明Proof-of-WorkCAPTCHA 浏览器环境检查instrumentation后者可显著提高机器人的作弊门槛。Cap 生态为多种服务端框架提供了同构的官方中间件包Express 对应的是cap.js/checkpoint-express此外还有 Honocap.js/checkpoint-hono见 docs/zh/guide/middleware/hono.md与 Elysiacap.js/middleware-elysia见 docs/zh/guide/middleware/elysia.md。它们共享同一套参数设计本文对配置选项的讲解同样适用于其他框架。安装依赖在项目目录下运行bun add express cookie-parser cap.js/checkpoint-express这条命令会安装三个包包名作用expressWeb 服务端框架提供路由与中间件体系cookie-parser解析请求中的 CookieCheckpoint 中间件依赖 Cookie 来跟踪质询通过状态cap.js/checkpoint-expressCap Checkpoint 的 Express 官方中间件说明文档给出的包管理器是Bun仓库整体也基于 Bun 生态构建例如 core/package.json 与 standalone/package.json 均使用 Bun 管理。如果你使用 npm / pnpm请自行替换为对应的npm i/pnpm i命令。快速开始为 Express 应用接入 Checkpoint以下是从官方文档 docs/zh/guide/middleware/express.md 继承的完整示例。它演示了如何用中间件保护全部路由只有通过质询的客户端才能继续访问受保护内容import express from express; import cookieParser from cookie-parser; import path from path; import { dirname } from path; import { fileURLToPath } from url; import { capCheckpoint } from cap.js/checkpoint-express; const app express(); const __dirname dirname(fileURLToPath(import.meta.url)); app.use(express.json()); app.use(cookieParser()); app.use( capCheckpoint({ /* token_validity_hours: 32, tokens_store_path: .data/tokensList.json, token_size: 16, verification_template_path: join(__dirname, ./index.html), */ }), ); app.get(/, (req, res) { res.sendFile(path.join(__dirname, success.html)); }); app.listen(3000, () { console.log(Server running on http://localhost:3000); });代码要点cookieParser()必须在capCheckpoint(...)之前注册因为质询通过后的令牌状态依赖 Cookie 传递capCheckpoint({...})以全局中间件形式挂载因此会拦截其之后注册的全部路由——示例中/路由返回的success.html只有通过质询的客户端才能看到示例中的配置对象全部处于注释状态此时使用默认配置即可直接运行。就是这么简单。运行后打开http://localhost:3000未通过质询的访问会被引导到浏览器检查过渡页完成工作量证明与浏览器环境检查后才会看到你的真实页面。配置选项详解示例注释中展示的四个选项是这套中间件的核心参数其语义可由官方文档与仓库内其他框架文档docs/zh/guide/middleware/hono.md、docs/zh/guide/middleware/elysia.md交叉印证选项类型/默认值含义token_validity_hours小时数默认 32质询通过后颁发的令牌有效时长。超过此时长后客户端需要重新完成质询tokens_store_path文件路径如.data/tokensList.json令牌存储位置。Checkpoint 中间件在本地文件系统中记录已颁发/待校验的令牌token_size字节数默认 16令牌的大小字节影响令牌熵值与不可预测性verification_template_pathHTML 文件路径浏览器检查过渡页的模板文件即质询页面的 HTML完整启用全部自定义配置的写法如下import { join } from path; app.use( capCheckpoint({ token_validity_hours: 32, // 令牌有效时长小时 tokens_store_path: .data/tokensList.json, // 令牌列表存储文件 token_size: 16, // 令牌大小字节 verification_template_path: join(__dirname, ./index.html), // 质询过渡页模板 }), );验证模板与/__cap_clearanceverification_template_path指向的 HTML 模板是 Checkpoint 的核心 UI。从 docs/zh/guide/middleware/elysia.md 的说明可以确认模板中只需包含一个指向/__cap_clearanceURL 的验证组件cap-widget或隐藏求解器Checkpoint 中间件会在该 URL 上完成质询的签发、校验与放行逻辑。也就是说你不需要在模板里手写任何质询协议逻辑只需要引入 Cap 验证组件Widget的脚本在模板中放置一个cap-widget元素或隐藏求解器让验证组件指向/__cap_clearance中间件会自动接管后续流程。验证组件Widget的完整用法可参考 docs/zh/guide/widget.md。令牌如何被校验从质询通过到放行要真正理解这套中间件的安全性需要知道质询通过之后发生了什么。Cap 生态的校验链路在服务端源码中有清晰的实现以 standalone/src/siteverify.js 为例cap.js/checkpoint-express与 Cap Standalone 后端共享相同的令牌校验语义可以归纳出以下关键环节1. 令牌格式。站点验证时response客户端提交的令牌必须能被:分隔成三段见 standalone/src/siteverify.js第一段是站点密钥。格式不合法会直接返回400。2. 站点密钥与秘密密钥校验。服务端根据站点密钥查找对应的secretHash哈希存储不保存明文通过 standalone/src/secret-hash.js 中的verifySecret校验提交的secret不匹配返回403。3. 令牌的一次性消费与过期。服务端使用GETDEL语义standalone/src/siteverify.js读取并删除令牌令牌必须存在否则404、必须未过期否则403并且每个令牌只能被成功验证一次防止重放攻击。4. 成功响应。全部校验通过后返回{ success: true }。因此无论使用哪个接入方式Checkpoint 中间件或直接对接 Standalone你的后端都永远不要信任客户端传来的未经验证的令牌——必须先经过上述校验流程才能认为该请求来自已通过质询的真实浏览器。与 Cap Standalone 后端配合完整的生产部署形态cap.js/checkpoint-express解决的是“入口拦截”这一层而质询本身的签发、令牌的最终校验则依赖一个 Cap 服务端。官方推荐的部署方式是Cap Standalone详见 docs/zh/guide/standalone/index.md它运行在 Bun 上空闲内存占用约 50 MB内置 instrumentation浏览器环境检测质询并提供兼容 reCAPTCHA 的siteverifyAPI 与一个管理站点密钥的 Web 控制台推荐用 Docker Compose 一键启动镜像tiago2/cap:latest搭配 Valkey/Redis 存储随后在控制台创建站点密钥记下站点密钥site key与秘密密钥secret key客户端验证组件通过data-cap-api-endpointhttps://instance_url/site_key/指向你的实例docs/zh/guide/standalone/index.md用户完成 CAPTCHA 后后端向instance_url/site_key/siteverify发送POST { secret: ..., response: ... }验证令牌docs/zh/guide/standalone/index.md。在生产环境中将 Checkpoint 的验证模板指向你的 Standalone 实例即可形成完整闭环Express 入口拦截 → 质询过渡页 → Cap Standalone 签发与校验 → 放行受保护路由。部署时还需注意Standalone 实例必须能从公网访问验证组件才能与它通信如果部署在反向代理后面请按 docs/zh/guide/standalone/options.md 中的说明配置速率限制与客户端 IP 识别X-Forwarded-For/X-Real-IP等头/siteverify端点默认不做速率限制因为它面向服务器间调用docs/zh/guide/standalone/options.md。注意事项与适用前提环境要求官方文档以 Bun 为包管理器与运行环境仓库整体基于 Bun 构建建议在 Bun 运行时下使用以获得与文档一致的行为。影响搜索引擎爬虫如前文所述Checkpoint 会拦截所有未通过质询的客户端包括善意爬虫。如果 SEO 对你的业务至关重要需要谨慎评估或只在敏感路由上启用。默认配置即可运行不传任何配置时中间件使用内置默认值令牌有效期 32 小时、令牌大小 16 字节、默认存储路径适合快速验证正式上线前再显式配置verification_template_path与持久化路径。小结接入 Cap Checkpoint 到 Express 只需要三步安装cap.js/checkpoint-express、在cookieParser之后挂载capCheckpoint中间件、准备一个指向/__cap_clearance的验证模板。再结合 Cap Standalone 完成质询签发与siteverify校验你就在完全自托管、开源的条件下为自己的 Express 应用建立了一道复刻 Cloudflare 风格的浏览器检查防线——不依赖任何第三方闭源验证码服务。赞分享网络安全应用安全后端【免费下载链接】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点击查看免费下载相关推荐在 Express 中集成 Cap Checkpoint用 cap.js/checkpoint-express 为路由加上自托管的工作量证明 CAPTCHA 防线在 Express 中集成 Cap Checkpoint用 cap.js/checkpoint express 为路由加上自托管的工作量证明 CAPTCHA网络安全应用安全后端Cap Express Checkpoint 接入指南用 cap.js/checkpoint-express 为路由加装自托管工作量证明验证Cap Express Checkpoint 接入指南用 cap.js/checkpoint express 为路由加装自托管工作量证明验证 本指南讲解如何网络安全应用安全后端OMI macOS 桌面端 SwiftUI/AppKit 运行时调试手册从第一个不可能转变到持久化防护OMI macOS 桌面端 SwiftUI/AppKit 运行时调试手册从第一个不可能转变到持久化防护 导读 当 macOS UI 故障的可见表象无法直网络安全应用安全后端上一篇WTF-Solidity 实战用 Solidity 从零搭建零手续费去中心化 NFT 交易所 NFTSwap下一篇ReactXP VirtualListView 深度指南跨平台虚拟化列表的实现原理与性能优化实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考