
五步自建激活验证服务器WebToApp 的 Cloudflare Worker 示例完整拆解【免费下载链接】web-to-appThe most full featured web-to-app toolkit on Android, a complete APK workshop that runs entirely on your phone项目地址: https://gitcode.com/GitHub_Trending/web/web-to-appWebToApp一个完全运行在手机上、功能最全的 Web-to-App 工具箱可把网页直接打包成 APK内置了激活码验证功能。除了把码写死在 APK 里它还支持远程激活把码放到你自己搭建的服务器上随时吊销、随时轮换不用再重新打包 APK。本文带你完整拆解仓库里现成的 examples/remote-activation-worker 示例——一个跑在 Cloudflare Worker 上的自建激活验证服务器从生成签名密钥、部署上线到写入激活码五步全部走通。为什么值得自建一个激活验证服务器本地激活码一旦打包进 APK就焊死了想吊销一个泄露的码只能重新打包发布。换成远程验证后一切变得灵活随时吊销删掉服务器上的码立刻失效不用动 APK动态发放码库存放在 Workers KV一条命令就能新增设备绑定一码一次、单设备占用靠服务器集中记账签名响应每个响应都用 EC P-256 签名伪造服务器和中间人无法伪造ok: true⚡零后端运维Cloudflare Worker 按量计费、无需维护服务器客户端协议完整定义在 remote-activation.mdApp 端的校验逻辑实现在 RemoteActivationVerifier.kt应用侧的配置说明见 activation.md。示例目录结构一览整个示例非常精简就 4 个文件文件作用src/index.jsWorker 主体GET /自检 POST /verify验码并签名wrangler.toml部署配置KV 绑定、时钟漂移容忍度package.json脚本入口check/dev/deploy/kv:createtest/protocol-check.mjs协议自检模拟 KV 驱动真实 Worker按 Android 客户端同款逻辑验签第一步生成 EC P-256 签名密钥对安全设计的核心是非对称签名Worker 用私钥签名App 用公钥验签——公钥可以光明正大写进 APK私钥只有 Worker 持有。用 OpenSSL 两条命令生成# 私钥PKCS#8、单行 Base64—— 作为 Worker 的 SIGNING_KEY openssl ecparam -genkey -name prime256v1 -noout -out ec.pem openssl pkcs8 -topk8 -nocrypt -in ec.pem -out ec-pkcs8.pem openssl base64 -A -in ec-pkcs8.pem -out ec-pkcs8.b64 # 公钥SPKI Base64—— 填进 App 的Signature public key字段 openssl ec -in ec.pem -pubout -out ec-pub.pem openssl base64 -A -in ec-pub.pem -out ec-pub.b64⚠️ 私钥文件务必远离 git 仓库公钥不是秘密放心分发。第二步部署 Worker 到 Cloudflare在 examples/remote-activation-worker 目录下npm install npx wrangler login npm run kv:create # 打印出的 id 粘贴进 wrangler.toml npx wrangler secret put SIGNING_KEY ec-pkcs8.b64 npx wrangler deploy密钥只通过wrangler secret put注入绝不提交进仓库见 wrangler.toml 的注释约定。部署完先在浏览器打开 Worker 地址自检。健康的 Worker 会返回类似这样的 JSON{ ok: true, publicKey: MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE…, keyFingerprint: 3f9a1c02…, urlEncryption: disabled, problems: [] }publicKey直接复制进 App 的签名公钥输入框即可problems非空则 Worker 会拒绝一切验证并告诉你原因自检逻辑见 src/index.js。第三步写入激活码一条命令一个码码存在 Workers KV 里键为code:加大写码值# 不限次数的码 npx wrangler kv:key put --bindingACTIVATION_CODES code:DEMO1234 {note:demo} # 固定到期 一码一设备 npx wrangler kv:key put --bindingACTIVATION_CODES code:YEAR2027 \ {expiresAt:1798761600000,maxDevices:1,devices:[]} # 锁定指定包名并下发加密的目标 URL npx wrangler kv:key put --bindingACTIVATION_CODES code:VIP0001 \ {packageName:com.example.app,url:https://example.com/target,encryptUrl:true}码记录的字段速查字段含义expiresAt到期时间epoch 毫秒省略则永不过期maxDevices可激活设备数座位数默认 1即一码一次devices已占座的设备 ID由 Worker 自动维护packageName设置后该码只对指定包名的 App 有效url/encryptUrl动态下发目标 URL可选 AES-256-GCM 加密需配置AES_KEY机密message验证成功时展示给用户的消息note你自己的备注永远不会离开服务器验码主流程时钟校验 → 查码 → 过期/包名/座位检查 → 签名返回集中在 handleVerify。第四步搞懂两个容易踩坑的协议细节这正是示例最值钱的部分——两处细节写错所有激活全部失败1. 签名字段叫sig不是signature。客户端只认sig。2. 被签名的负载有固定键序。签名覆盖的是手工拼接的紧凑 JSON键序为ok → expiresAt → remainingUses → nonce开启 URL 下发时追加urlnull会被收敛成0expiresAt或-1remainingUses。Worker 端刻意不用JSON.stringify而是逐字段手拼见 canonicalSignedPayload就是为了与客户端逐字节一致杜绝键序漂移。配套的安全机制还包括Nonce 回显每次请求带随机 nonce响应原样带回防重放⏰时钟漂移检查客户端时间戳与服务器偏差超过 24 小时MAX_CLOCK_SKEW_MS可在 wrangler.toml 收紧直接拒绝URL 加密开启encryptUrl时目标 URL 先做 AES-256-GCM 加密Base64(IV[12]‖密文‖GCM tag[16])见 encryptUrl再参与签名——防篡改靠签名防偷读靠加密设备绑定deviceBound: true时按maxDevices记账首台设备占座卸载重装也不丢座第五步上线前跑一遍协议自检改动任何逻辑后先跑npm run checktest/protocol-check.mjs 用 mock KV 驱动真实的 Worker再完全按 Android 客户端的方式复核同款负载拼接、同款 ECDSA P-256P1363 格式验签、同款 AES-GCM 解包。README 说得直白这是最快发现会悄悄弄坏所有已安装 App的改动的办法。上线前必须知道的两件事 1. URL 下发是双边约定。激活请求里不携带我是否期望收到 URL的标志所以规则是带url的码只配开了 Deliver target URL 的 App不带的配没开的。配错后双方签的负载不同每次激活的验签都会失败。2. Workers KV 是最终一致、没有 compare-and-swap。两台设备同一瞬间抢最后一个座位时可能都成功。对大多数 App 可接受若不能接受把记录存储换成 D1 或 Durable Object 即可——签名路径完全不变只改get/put。 另外提醒验证运行在客户端远程验证的价值在于提高门槛吊销、轮换、防伪造而非防破解的银弹。详见 remote-activation.md 开头的安全说明。写在最后从生成密钥到跑通自检整套流程不超过十分钟而且全部跑在 Cloudflare 的边缘网络上——没有服务器要维护没有数据库要备份。码在 KV 里增删改App 侧只填一个 URL 和一把公钥。如果你的激活需求再复杂一点比如按码查用户、扣减余额也完全可以基于 src/index.js 这个约 300 行的参考实现往上加只要签名负载的键序和字段名保持和 RemoteActivationVerifier.kt 一致客户端就能无缝对接。【免费下载链接】web-to-appThe most full featured web-to-app toolkit on Android, a complete APK workshop that runs entirely on your phone项目地址: https://gitcode.com/GitHub_Trending/web/web-to-app创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考