OpenClaw配置Bot接入飞书机器人+Kimi2.5

OpenClaw配置Bot接入飞书机器人+Kimi2.5

上一篇文章写了Ubuntu_24.04下安装OpenClaw的过程,这篇文档记录一下接入飞书机器+Kimi2.5。

准备工作

飞书

创建飞书机器人

访问飞书开放平台:https://open.feishu.cn/app,点击创建应用:

填写应用名称和描述后就直接创建:

复制App ID 和 App Secret

创建成功后,在“凭证与基础信息”中找到 App ID 和 App Secret,把这2个信息复制记录下来,后面需要配置到openclaw中

配置权限

点击【权限管理】→【开通权限】

或使用【批量导入/导出权限】,选择导入,输入以下内容,如下图

点击【下一步,确认新增权限】即可开通所需要的权限。

配置事件与回调

说明:这一步的配置需要先讲AppId和AppSecret配置到openclaw成功之后再设置订阅方式,要不然会提示一个错误。

订阅方式选择【使用长连接接收事件】

配置成功后如下图

添加事件,点击【添加事件】

至少需要开通以下权限

配置成功后如下图

回调配置(可选),如果配置的话,也选择【使用长连接接收事件】

配置完成后需要进行发布,有2种方式:

方式1:创建版本

方式2

创建版本

发布成功后,状态显示:当前修改均已发布

说明:

(1)只有机器人的状态为已发布,openclaw才能识别

(2)有任何修改和配置的修改,都需要创建新的版本进行发布;

申请Kimi Code的AppKey

(1)访问https://www.kimi.com/code

(2)登录后,购买套餐 plan,目前 OpenClaw 消耗 token 还挺大的,最好买个套餐划算一些,我买的是 Moderato 套餐。

(3)点击【控制台】→【新建API key】

名字随便起

这个API key一定要复制下来,因为你点完【完成】之后,你就再也无法查看你的API key了,如果你忘记了你的API key,那就只能重新创建一个了。复制完后,找地方先保存起来,后续在OpenClaw配置的时候会用到。

下面的使用记录能看到你最近的使用记录。

openclaw配置

在安装了openclaw的服务器上输入

openclaw onboard

选择Yes

选择QuickStart

因为前面配置过,所以提示是否用原来的配置信息,可以使用Reset进行重置

选择:Moonshot AI(Kimi K2.5)

下一步就是输入Kimi控制台申请的API key

其他的配置还是按以前的配置就可以,具体可以参考前一篇blog内容。

飞书的插件是要进行安装的,现在openclaw的配置界面里面也支持了飞书,我通过openclaw的配置安装了几次,并没有成功,提示缺少包或插件重复

openclaw正常安装之后,我在想是不是可以让它来帮我解决这个问题,尝试了一下,我告诉它飞书插件一直安装不成功,让它进行修复,修复完成后给飞书机器人发信息会有回应。

看到飞书机器人的回复,飞书的配置就算是成功了,你可以直接给飞书机器人发信息,告诉它你的需求,它收到你的问题后会回复一个表情确认收到,如果没有收到的话可能就要看它是不是还在线了。

Read more

GHCTF2025-WEB题解:如何用SSTI绕过WAF黑名单(附实战payload)

从GHCTF2025实战出发:深度拆解SSTI黑名单绕过策略与高阶Payload构造 最近在GHCTF2025的WEB赛道上,一道看似简单的文件上传题目,却让不少选手陷入了“知道有洞,但payload总被拦截”的困境。这道题表面上是文件上传,实际上却是一场针对SSTI(服务器端模板注入)绕过能力的深度考验。我在实际测试中发现,很多选手能够快速识别出SSTI漏洞的存在,但在面对严格的黑名单过滤时,却往往束手无策,反复尝试的payload都被WAF无情拦截。 这种情况在真实的渗透测试和CTF比赛中并不少见。WAF(Web应用防火墙)的过滤规则越来越智能,传统的{ {7*7}}测试虽然能确认漏洞,但真正要执行命令、读取文件时,那些包含os、flag、__builtins__等关键词的payload几乎都会被第一时间拦截。这道题的精妙之处在于,它模拟了一个相对真实的防御环境——不仅过滤常见敏感词,还对下划线这种在Python反射中至关重要的字符进行了拦截。 本文将从实战角度出发,不局限于GHCTF2025这一道题目,而是系统性地探讨SSTI黑名单绕过的核心思路、技术原理和进阶技巧。我会结

前端通用 Token 全流程操作指南(常见常用版)

前端通用 Token 全流程操作指南(常见常用版) 本文梳理 所有前端框架通用 的 Token 操作逻辑,剥离具体项目/技术栈细节,聚焦「获取→存储→使用→过期→清除」的核心生命周期,每个步骤均标注「通用场景+通用方案+注意事项」,适合所有前端开发场景,可直接作为开发速查表。 前置说明:Token 的核心定位 Token 是后端签发的临时访问凭证,核心作用是: 1. 证明“当前用户是谁”(身份认证); 2. 证明“当前用户有权限访问”(权限校验)。 一、第一步:登录成功获取 Token 通用场景 用户通过账号密码/验证码/第三方登录等方式,向后端发起登录请求,后端验证通过后,在响应体中返回 Token。

前端图片加载失败、 img 出现裂图的原因全解析

在前端开发过程中,我们几乎都遇到过这种情况: 页面中某张图片加载不出来,显示成一个小小的“裂图”图标。 这看似简单的问题,实际上可能由多种原因造成,尤其是在 HTTPS 环境下,混合内容机制(Mixed Content) 是最常见、也最容易被误解的根源之一。 本文将带你系统梳理裂图的各种原因、排查思路,并重点讲清楚混合内容的原理与浏览器行为。 一、什么是“裂图”? “裂图”(broken image)是指浏览器尝试加载 <img> 标签的图片资源失败时的表现形式。 常见表现: * 图片区域显示为灰底、叉号、占位符; * 控制台出现 Failed to load resource 或 Mixed Content 警告; * Network 面板中图片请求状态码为 404 / 403 / blocked。 二、常见的裂图原因汇总

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

WebRTC / HLS / HTTP-FLV 的本质区别与选型指南

在做系统级直播(而不是自己本地播放)时,很多人都会遇到一个经典问题: WebRTC、HLS、HTTP-FLV 到底有什么区别? 项目中到底该选哪个? 传输协议不同 → 延迟不同 → 兼容性 / 稳定性 / 成本不同 在系统里选哪个,核心看两点: 你要多低的延迟?你要多强的兼容和稳定? 一、简介 * WebRTC:超低延迟(0.2 ~ 1s),适合实时监控、无人机、实时指挥 * HLS(hls.js):最稳、最通用(5 ~ 15s),适合活动直播、课程、公开大并发 * HTTP-FLV(flv.js):中低延迟(1 ~ 3s),适合想比 HLS 低延迟,但不想用 WebRTC 的场景(