|
|
23d35cd942
|
refactor(common): 通知实现搬进 common.js，所有脚本一行 require 即可用
上一版把 notify 内联在 qqmusic 脚本里，只解决了单个脚本。这次搬到仓库根的
common.js，后续任何脚本 require('../common') 就能发通知。
common.js 新增导出：
notify(title, content, opts) webhook + pushplus 双通道，任一成功即 ok，永不抛错
notifyConfig(env) 读 env 并给默认值（可注入替身，方便测试）
httpPost(url, headers, body) 通用 POST，http/https 自适应
parseHookHeaders(raw) 一行一个 Key: Value
buildHookBody(t, c, tpl, ct) 拼 body，JSON 不合法就重建
Env 保持原样未动（jd 与 xiequ 在用）。
顺带删掉第 1 行的 require('node-fetch') —— 它是死代码：Env 内部所有 HTTP 走的是
require('got') + require('tough-cookie')，fetch 只以 $task.fetch(...) 的形式出现在
QuantumultX 分支（宿主 API，不是 node-fetch）。留着它反而会在容器缺 node-fetch 时
让整个文件 require 抛错，连带 jd / xiequ 一起挂。
qqmusic 脚本从 125 行内联实现缩成一行 require('../common')，删掉重复的
httpPost / parseHookHeaders / buildHookBody / notify 四份副本。
测试从 qqmusic/test_notify.js 挪到仓库根 test_common_notify.js，断言从 38 加到 69：
- parseHookHeaders 九种输入（新增重复 key 覆盖）
- buildHookBody 五种（新增自定义模板 + urlencoded + text/plain）
- notifyConfig 十项默认值与 trim
- notify 八种状态（200/204/201/401/403/400/429/连不上）
- 无配置、双通道互不牵连
- Env 兼容性（确认 node-fetch 已移除、老接口都在）
端到端已验证：common.js 的 notify 发出的 content 与原始 desp 逐字相同（10 行完整），
title 正确，header 带 token，HTTP 204 判为成功。
README（根 + qqmusic）新增 common.js 公共库章节，列出 notify 支持的八个环境变量
与「为什么不能放 sendNotify.js」的 deps 覆盖原因。
|
2026-11-07 02:10:23 +08:00 |
|
|
|
3a711d0a47
|
fix(notify): 平台回 204 被误判为失败 + 诊断工具改名 scrip_
三个改动：
1) sendNotify.js 的 webhook 判据从 statusCode !== 200 改成 2xx 一律成功。
平台 /api/hooks/ql 按设计回 204（表示已接收且不写 event_logs），
原判据把 204 当失败 → 每轮日志都打「自定义发送通知消息失败！！」，
而投递其实成功了。这是纯假警报，也是这次误判的根因。
同时把状态码打进日志，真失败时能直接看出是 401/403/400/429。
2) _diag_notify.js → scrip_diag_notify.js。
订阅白名单是 scrip_，不带前缀的文件拉不下来，工具等于不存在。
加 // cron: 0 0 1 1 * 与 // name:，避免青龙自动建任务时落随机 cron。
正文补到六段：sendNotify 加载 / env / webhook 三前置条件与 body+headers
解析复刻 / 直打平台按状态码定位 / pushplus txt-vs-html 模板对比 /
完整 sendNotify 对照。
3) 文档补齐平台侧的两道硬校验：来源 IP 必须 127.0.0.1 或 172.16/12
（走公网域名会变成反代地址 → 403），回环带 XFF 一律 403。
给出指向平台的完整 env 写法（WEBHOOK_BODY 必须多行，单行 JSON
会被 parseString 整段吞掉 —— 已实测解析结果为 0 个 key）。
验证：node --check（sendNotify + 诊断）/ 5 个 mock 状态码用例
（204/401/403/400/429）全部被正确识别 / _probe_meta 四文件 PASS
|
2026-11-05 09:34:06 +08:00 |
|
|
|
87debf37a9
|
chore(meta): 三个脚本统一青龙元数据注解，新增 _probe_meta.js 自检
继 3531437 修好 qqmusic 之后，把同一问题在另两个脚本上一并清掉 ——
它们原本都没写 name 注解（任务名会退回文件名），且 jd 脚本的 cron 写在块注释里
用了 */ 转义，青龙会把反斜杠一起提取出去。
改动（三个脚本统一成同一形态：文件最前面两行行注释）：
// cron: <表达式>
// name: <中文任务名>
- jd/scrip_moving_env_enhance.js: 补 name 注解；cron 从块注释移到行注释
（原来写的 \*/ 转义会产出非法表达式）
- xiequ/scrip_switch.js: 补 name 注解；正文两处日志里的「name: xxx」改成「账号 xxx」
（青龙的任务名正则不锚定行首、取全文第一个命中，正文命中会盖掉注解）
- qqmusic/scrip_qqmusic_checkin.js: 注解从块注释改成行注释，与另两个统一
- 新增 _probe_meta.js: 扫描所有 scrip_*.js，复刻旧版（/name:\s*(.+)/ 不锚定）
与新版（cli/src/internal/subscription 的 cronMetadata）两条提取逻辑，
断言任务名不是代码片段、cron 是合法表达式。不带 scrip_ 前缀，订阅不会拉取
验证：_probe_meta.js RESULT: PASS（3 个文件，两个版本青龙提取都正确）/
三个脚本 node --check 全过 / qqmusic 签名对拍 6 组 PASS / 空 env 优雅跳过
|
2026-11-04 21:22:38 +08:00 |
|
|
|
68721d1abb
|
refactor(qqmusic): 脚本改名 scrip_qqmusic_checkin.js 以匹配订阅白名单
订阅规则 ql repo 的 whitelist 参数是 "scrip_"，只有文件名带该前缀的才会被拉取。
原文件名 qqmusic_checkin.js 不在白名单内，青龙订阅拉不到。
- qqmusic/qqmusic_checkin.js -> qqmusic/scrip_qqmusic_checkin.js（git mv 保留历史）
- test_sign_run.js 的 require 路径同步
- qqmusic/README.md 与根 README.md 更新文件名与白名单约定说明
- 根 README 补 QQ音乐条目（环境变量 SH_QQMUSIC_KEY / cron 1 0,6 * * *）
依赖拉取不受影响：订阅命令的 dependence 参数 sendNotify|common 会额外拉这两个文件，
脚本的 require('../sendNotify') 仍指向青龙内置/仓库根的 sendNotify.js。
验证：node --check 通过 / 签名对拍 6 组向量全 PASS / 空 env 优雅跳过 /
单账号与 & 多账号解析正确 / 整串 cookie 形态解析正确
|
2026-11-04 20:49:54 +08:00 |
|
|
|
b9b407737a
|
docs(readme): 更新脚本列表信息
- 新增京东Cookie辅助脚本说明
- 新增携趣白名单切换脚本说明- 补充脚本定时规则与环境变量配置
- 调整文档结构便于查阅chore(scripts): 更新携趣切换脚本定时规则
- 将执行时间从 0 12 * * * 调整为 38 2,8,14,20 * * *
- 优化脚本执行频率以提高效率
|
2025-11-02 18:38:50 +08:00 |
|
|
|
90f9ad9a5d
|
chore(config): 更新开发脚本和文档说明
- 更新 README 中的快速开始指南，使用 ql repo 命令替代手动克隆步骤
- 移除旧的环境配置说明
- 添加新的订阅方式说明
|
2025-11-02 18:14:49 +08:00 |
|
|
|
625a6ea2f9
|
feat(xuequ): 添加携趣白名单切换脚本
- 新增 switch.js 脚本，用于自动切换携趣代理的白名单IP
- 支持多账户和多IP配置，通过环境变量 XQ_ACCOUNTS 和 XQ_WHITELIST 设置
- 实现获取当前白名单、删除所有白名单、选择剩余次数最多的账户并添加新白名单的功能
- 集成定时任务，可通过 cron 表达式设置执行时间
- 添加详细的日志输出和错误处理机制
|
2025-11-02 17:16:09 +08:00 |
|
