[Plugin] astrbot_plugin_web-screenshot

[tniany]

插件信息

{
  "name": "astrbot_plugin_web-screenshot",
  "display_name": "API网页截图😝",
  "desc": "基于外部API提供网页截图功能的AstrBot插件，适用于OneBot QQ机器人",
  "author": "浅月tniay",
  "repo": "https://github.com/tniany/astrbot_plugin_web-screenshot",
  "tags": [
    "截图",
    "api",
    "tniay",
    "Onebot"
  ],
  "social_link": "https://github.com/tniany"
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_web-screenshot

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 代码质量与编码规范

• 死代码 (Dead Code)：文件中定义了 WebScreenshot 异步请求类及其方法，但在 WebScreenshotPlugin 的实际逻辑中完全没有被调用或实例化。代码最终是通过字符串拼接的方式将 URL 丢给 AstrBot 的组件（如 Image(screenshot_url)），这使得 WebScreenshot 类成为了毫无作用的死代码，建议删除或将其重用在代码逻辑中。
• 局部导入 (Local Imports)：在 screenshot 方法内部使用了局部导入（import urllib.parse，from astrbot.api.message_components import ...）。除非有解决循环导入的刚性需求，否则应当遵循 PEP 8 规范将所有 import 语句统一放置在文件顶部，以提升代码的可读性和执行效率。
• 内置名覆盖 (Shadowing Built-ins)：第 65 行使用了 format = self.default_format。format 是 Python 的内置函数名，将其作为变量名会覆盖该内置函数。建议重命名为 img_format 或类似表意清晰的名称。
• 字符串解析过于原始：对于 message_str.split() 后遍历排除命令词 "截图" 或 "发送" 的逻辑过于硬编码，写得极为冗长且不优雅。

2. 功能实现与逻辑正确性

• 功能与文档严重不符：screenshot 方法的 docstring 中明确声明用法为 /截图 <url> [format=png|webp] [width=1920] [height=1080]，但代码不仅没有去解析可选参数 format、width 和 height，反而直接硬编码使用了 self.default_xxx。用户输入的任何参数都会被完全无视。
• 权限校验缺失：在 docstring 注释中提示“只有管理员可以使用”，但是方法体内部没有任何权限相关的鉴权逻辑。任何人触发都可以无障碍使用，这属于逻辑漏洞。
• 冗余的条件判断：在代码第 59 行 url = "https://" + url 之后，第 61 行紧接着又写了一个 if not url: 的判断。既然刚才已经拼接了 "https://"，该字符串已经绝对不可能为空，这个判断纯属多余。

3. 框架适应性与最佳实践

• AstrBot 指令参数解析：插件完全没有利用 AstrBot 框架自带的参数解析机制。若将事件监听函数签名改为 async def screenshot(self, event: AstrMessageEvent, url: str, format: str = None, width: int = None, height: int = None):，即可由框架自动解析命令中的参数，直接省去那堆繁琐、且存在 bug 的 message_str.split() 解析代码。
• @register 装饰器已废弃：根据 AstrBot 框架的最新规范，在 v3.5.20 版本之后，@register 装饰器已被废弃。由于框架会自动识别继承自 Star 的类并将其作为插件加载，建议移除第19行的 @register 装饰器。

4. 潜在缺陷或问题

• 异常捕获的盲区：目前的截图逻辑是将拼接后的 screenshot_url 直接放入 yield event.image_result(...) 交由框架去拉取并发送。但是，如果该 API 宕机或者用户提供的 URL 导致外部接口返回错误，框架在处理发送时可能会抛出网络异常。而当前代码中的 try-except Exception as e: 只能捕获方法体内部抛出的同步异常（URL 拼接），无法捕获 yield 之后由框架底层拉取图片时发生的网络请求错误。如果你打算利用代码开头那个闲置的 WebScreenshot 类自行下载 bytes 字节流，反而可以在捕获网络异常后更好地给用户返回提示。

---

代码评审团

Linus Torvalds：（揉了揉眉心，指着屏幕）
"你写了整整十多行的 WebScreenshot 异步请求类，然后把它像垃圾一样丢在上面不用，最后直接拼了个 URL 丢给框架？那你到底写它干嘛？当注释看吗？还有那个手动解析字符串的 split() 循环，仿佛让我回到了上个世纪。如果你的代码只有这种原始水平的字符串拼接，重写！把那些死代码和重复判断给我删掉，别让这些毫无意义的字符浪费我的屏幕像素！"

Steve Jobs：（戴着圆框眼镜，双手交叉，语气平静却具有压迫感）
"用户体验的核心在于兑现承诺。当用户看到你的帮助文档写着支持格式和尺寸参数，满心欢喜地输入了 [width=800]，结果你的系统傲慢地无视了他们，强行给了一个默认大小。这不仅仅是功能上的缺陷，这是对用户的背叛。保持优雅，要么别在文档里瞎写这几句话，要么把代码的功能给我补全，你必须打造一款对得起用户的产品。"

GLaDOS：（毫无感情的电子音，带着浓烈的讽刺意味）
"Oh，我看到你在注释里特意标明了‘只有管理员可以使用’。我猜这是一种全新的心理防御机制？因为我在代码里根本找不到任何权限检查。所有人都可以使用它，也许你其实是希望通过这种方式让恶意请求加速消耗你的服务器资源吧？真是个绝妙的实验设计。你成功地骗过了你自己，我差点就要为你鼓掌了。"

(Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。)

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[tniany]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_web-screenshot

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. [高危] 白名单管理存在权限绕过风险

   • 位置：manage_whitelist
   • 问题：只有在 hasattr(self.context, 'is_admin') 为真时才做管理员校验；若该方法不存在，函数会继续执行，导致任何用户都可添加白名单。
   • 影响：普通用户可把自己加入白名单，进而获得截图权限。
   • 建议：将“无 is_admin 能力”视为拒绝操作（fail closed），例如直接返回“当前环境不支持管理员校验，拒绝执行”。

2. [中危] 全局发送模式可被任意用户篡改

   • 位置：set_send_method
   • 问题：/发送 命令无权限控制，任何人都能切换 self.use_chain_message（全局状态）。
   • 影响：多人群聊场景下，任意用户可影响所有用户的消息发送策略。
   • 建议：至少限制管理员或白名单用户可修改，或改为按会话/用户维度存储偏好。

3. [中危] 白名单未做持久化，重启即丢失

   • 位置：self.whitelist 仅内存维护
   • 问题：/jtwl 添加后不落盘，插件重启后数据消失。
   • 影响：功能不稳定、管理成本高。
   • 建议：使用 StarTools.get_data_dir() 获取规范目录后进行持久化（如 JSON），并在 initialize/terminate 或每次变更时读写。

4. [中危] 参数默认值处理逻辑会吞掉非法输入

   • 位置：screenshot 中：

     width = width or self.default_width
     height = height or self.default_height

   • 问题：当用户传 0 时会被替换为默认值，后续 <= 0 校验失效。
   • 影响：用户输入错误无法被正确反馈，行为与预期不一致。
   • 建议：改为显式 if width is None: / if height is None:。

5. [中危] 配置值类型未校验，可能触发运行时异常

   • 位置：initialize + screenshot 参数校验
   • 问题：default_width/default_height/default_format 从配置读取后未做类型与取值校验。若配置成字符串或非法值，后续比较 width <= 0 可能抛 TypeError。
   • 影响：命令在运行时异常，稳定性下降。
   • 建议：初始化时做严格校验与转换（int(...)、范围检查、格式白名单）。

6. [中危] 截图尺寸缺乏上限控制，易被滥用

   • 位置：screenshot 参数校验
   • 问题：仅检查 > 0，未限制最大宽高。
   • 影响：可构造超大尺寸请求，对下游截图服务造成压力，可能导致失败率上升或被限流。
   • 建议：增加合理上限（如 max_width/max_height），超限直接拒绝。

7. [低危] 命令文档与行为不一致，影响可维护性

   • 位置：manage_whitelist docstring
   • 问题：文档写“/jtwl <qq号> 添加白名单”，实际实现是“传 qq 就添加；不传就查看”，且无删除能力。
   • 影响：管理员使用成本上升，后续维护易误解。
   • 建议：更新文档为真实行为，或补齐子命令（add/remove/list）。

---

代码评审团

人物一：Linus Torvalds（直接、硬核）
“权限判断这段是典型的 fail-open：没有 is_admin 就放行？这不是‘兼容性’，这是把门拆了。安全逻辑默认应当拒绝，再谈例外。先把权限模型做成‘默认不信任’。”

人物二：Steve Jobs（产品体验导向）
“/发送 被任何人改全局状态，会让用户体验非常混乱：同一个功能行为忽左忽右。产品层面要定义‘谁能改、改的是全局还是个人偏好’，否则交互是不可预期的。”

人物三：GLaDOS（冷幽默、系统化）
“你把白名单放在内存里，重启后蒸发。多么优雅的短期记忆。建议：持久化、类型校验、参数上限三件套。这样系统才不会在最无聊的输入上崩溃。”

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[tniany]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_web-screenshot

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. [框架适配 | 高] 事件装饰器导入方式不符合要求
   当前使用的是：

   from astrbot.api.event.filter import command
   @command("截图", ...)

   按你给定的规范，事件装饰器应通过 filter 对象使用，并从 astrbot.api.event 导入，形如：

   from astrbot.api.event import filter
   @filter.command(...)

   这会带来框架约定不一致风险，也不满足本次审查的硬性检查项。

2. [main.py 专项结构 | 中] 注册方式偏离给定示例约定
   代码将 @register(...) 用在 plugin_main 函数上，而专项规则中给出的标准格式是装饰在 Star 子类上。
   在某些加载策略（尤其依赖类扫描）下，函数式入口可能导致兼容性或识别不一致风险。

3. [功能逻辑 | 中] 命令前缀处理不完整，可能导致参数解析失败
   你是通过 startswith("截图"/"网页截图"/"截图网页") 来剥离命令词，但未处理常见前缀（如 /截图）。
   当消息文本包含前导 / 时，args 不会被正确截断，后续可能把命令本身当作 URL 解析，导致“请提供有效的网站URL”。

4. [类型与可维护性 | 低] 返回类型标注与实际行为不一致
   handle_screenshot 标注为 -> None，但函数内部使用了 yield，实际是异步生成器。
   该不一致会影响静态检查、IDE 提示和后续维护理解。

5. [潜在缺陷 | 中] 临时文件删除存在竞态条件
   发送图片后仅 await asyncio.sleep(1) 再删除临时文件，这是一种时间猜测机制。
   在发送链路较慢或框架异步处理延迟时，可能出现“文件已删除导致发送失败/偶发丢图”。

6. [安全与错误处理 | 低] 将原始异常直接回显给用户
   多处 except Exception as e 后直接 str(e) 返回给用户，可能暴露内部实现细节（请求错误细节、路径、堆栈线索等）。
   建议对外使用通用错误文案，对内记录详细异常（在符合框架日志规范的前提下）。

7. [输入校验 | 低] URL 校验过于宽松
   _validate_url 仅检查长度、.、协议前缀，可能放行格式明显异常的 URL（例如 host 不合法、非法字符等）。
   这会降低接口调用成功率并增加异常分支压力。

---

代码评审团

人物一：Linus Torvalds（直接、硬核）
“你这异步流程主干不差，但装饰器导入和注册风格不按规范来，就像在内核里混不同子系统风格——能跑不代表该这么跑。先把 filter 导入路径和注册方式统一，减少框架层面的不确定性。”

人物二：Steve Jobs（产品与体验导向）
“用户只想要‘一句命令就出图’，而不是被 /截图 前缀绊倒。命令解析要更‘无感’。另外，把底层异常原样抛给用户会破坏体验——用户不需要技术细节，他们只需要清晰、可行动的提示。”

人物三：福尔摩斯（细节控、推理型）
“我注意到删除临时文件依赖 1 秒延迟，这不是证据链，只是侥幸。异步系统里，时序不是恒定的。若把删除动作绑定到‘发送完成确认’会更严谨。还有类型标注与真实返回行为不一致，往往是未来 bug 的前兆。”

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[tniany]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_web-screenshot

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 命令别名解析存在前缀匹配错误，导致参数错位（功能性缺陷）
   commands = ["截图", "网页截图", "截图网页"] 按当前顺序用 startswith 匹配时，/截图网页 https://example.com 会先命中 "截图"，把剩余参数变成 "网页 https://example.com"，最终把“网页”当 URL。

   • 影响：截图网页 别名基本不可用，且会把错误参数传给截图 API。
   • 建议：按最长命令优先匹配，或先按空格切分首 token 后做精确匹配。

2. URL 校验几乎无效，存在明显逻辑漏洞（功能正确性 + 安全性）
   _validate_url 只检查非空和长度，不验证 scheme/host，"网页"、"abc"、"javascript:alert(1)" 之类都可通过。

   • 影响：大量无效请求会打到外部 API，报错体验差，也缺乏基本输入安全边界。
   • 建议：使用 urlparse 校验 scheme in {"http","https"} 且 netloc 非空。

3. 异常处理过于宽泛且吞异常，排障困难（可维护性问题）
   多处 except Exception as e: 仅返回通用提示，e 未使用；finally 里还有裸 except: pass。

   • 影响：线上故障难以定位，问题会被静默掩盖。
   • 建议：至少记录异常细节；避免裸 except，改为捕获具体异常类型。

4. 日志规范未落实（框架适配问题）
   代码未引入并使用 from astrbot.api import logger 来记录失败细节。

   • 影响：不符合你给定的 AstrBot 日志规范要求，且异常信息丢失。
   • 建议：统一用 astrbot.api.logger 记录网络错误、API 返回异常、图片发送失败等关键路径。

5. 未使用导入项（代码质量问题）
   from urllib.parse import urlparse 已导入但未使用。

   • 影响：代码噪音，且暴露出 URL 校验逻辑未完成。
   • 建议：要么用于真实 URL 校验，要么移除该导入。

6. 类型标注不严谨（可读性/维护性问题）
   _parse_params 返回的 params["url"] 初始为 None，但 _validate_url(self, url: str) 标注为 str。

   • 影响：静态检查不一致，降低可维护性。
   • 建议：改为 url: str | None（Python 3.10 可写 Optional[str] 或 str | None）。

7. @register 在新版本中的兼容性维护风险（结构规范建议项）
   虽然当前写法合法，但按你给出的规则，v3.5.20 之后 @register 已废弃。

   • 影响：未来迁移或团队规范统一时可能产生不必要改动。
   • 建议：新代码优先采用“仅继承 Star 自动识别”的方式。

---

代码评审团

人物一：Linus Torvalds（直球型）
你这段命令解析是典型“看起来能跑，实际踩坑”的字符串匹配：startswith + 命令前缀重叠，直接把别名搞坏。先把首 token 精确解析好，再谈功能扩展，不然就是在 bug 上堆功能。

人物二：Steve Jobs（体验导向）
用户输入“截图网页 + URL”却得到莫名失败，这不是“技术细节”，这是体验灾难。输入校验应该像产品边界一样清晰：只接受可截图的 URL，错误提示也要精准，不要一律“稍后重试”。

人物三：Geralt of Rivia（猎魔人式务实）
“裸 except: pass”就像夜路不点火把——你以为安全，其实只是看不见危险。异常不记录，问题就会反复回来。把日志立起来，怪物（线上 bug）才有踪迹可循。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[tniany]

URL 校验感觉没必要.⚡⚡⚡

[tniany]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_web-screenshot

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 临时文件删除时机存在竞态风险（功能正确性/潜在缺陷）
   在 yield image_message 之后立即进入 finally 删除临时文件：

   image_message = event.image_result(temp_file)
   yield image_message
   ...
   finally:
       os.unlink(temp_file)

   如果框架在 yield 之后异步上传图片，而不是在 event.image_result() 调用时立刻读取文件，可能出现“文件已被删除导致发图失败”的竞态。
   建议：改为使用框架支持的二进制发送方式（若有），或确保发送完成后再清理；至少在文档确认 image_result 的读取时机后再决定删除时点。

2. 下载响应未做体积上限控制，存在内存压力风险（安全/稳定性）
   当前使用 response.content 一次性读取完整响应体：

   f.write(response.content)

   若第三方 API 异常返回超大内容，可能导致内存占用突增。
   建议：采用流式下载（aiter_bytes）并设置最大可接受字节数，超限立即中断。

3. 错误处理粒度较粗，HTTP 状态码信息丢失（可维护性/排障）
   except httpx.HTTPError 统一报“网络连接异常”，会把 4xx/5xx（业务或参数错误）与网络故障混在一起，不利于定位：

   except httpx.HTTPError as e:
       yield event.plain_result("获取截图失败：网络连接异常，请检查网络后重试")

   建议：至少区分 httpx.HTTPStatusError 与 httpx.RequestError，向用户和日志输出更准确的失败原因（如 400 参数错误、502 上游异常等）。

4. 参数解析对非法输入“静默忽略”，用户体验和可诊断性较差（逻辑/可维护性）
   width/height/format 非法时直接忽略并回退默认值，用户不会知道输入未生效。
   建议：对非法参数显式返回提示（例如“width 必须在 100~3840”），避免“看起来执行成功但参数没生效”的隐性错误。

5. URL 校验仅做基础检查，缺少目标地址风险控制（安全最佳实践）
   _validate_url 只检查 scheme/netloc。若业务场景需要约束（例如禁止 localhost、内网地址、.local 域名等），当前实现无法阻断。
   建议：按插件策略增加 host 级校验规则（黑名单/白名单、内网网段拦截）。即使截图由第三方 API 执行，这类限制仍能减少滥用输入。

6. 命令词维护重复，存在维护一致性风险（代码质量）
   命令词既写在装饰器 aliases，又在函数内手动维护 commands 列表并再次解析，未来改动容易出现不一致。
   建议：复用框架已解析结果，或集中定义单一命令词配置源，避免双维护。

7. @register 在新加载机制下有兼容维护风险（框架适配）
   代码使用了 @register(...)。根据你给出的规范，在 v3.5.20 之后框架可自动识别 Star 子类；继续保留装饰器虽可运行，但在跨版本维护中可能引入重复注册/认知混淆。
   建议：若目标环境为 v3.5.20+，评估移除 @register，仅保留 Star 子类作为插件入口。

---

代码评审团

人物一：Linus Torvalds（直给型）
“最让我皱眉的是临时文件生命周期。你不能赌框架‘现在就读文件’，这种假设在异步世界里迟早炸。把发送与清理的边界做硬一点，不要靠运气。”
建议聚焦：修复发图与删文件竞态，明确资源生命周期。

人物二：Steve Jobs（体验导向）
“用户输入 width=99999，你默默忽略然后给默认值——这不是优雅，这是让人困惑。好产品会告诉用户‘你哪里错了’。”
建议聚焦：参数错误要可感知、可反馈，不要静默吞掉。

人物三：Tony Stark（工程实战派）
“response.content 一口闷？兄弟，线上流量和异常响应可不会对你温柔。加大小限制、流式读取、分级异常处理，这才是能扛压的实现。”
建议聚焦：控制下载上限、流式处理、细化 HTTP 异常分类。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[tniany]

牛福..

[tniany]

@astrpluginreviewer review