fix(dingtalk): accept oapi.dingtalk.com webhook domain for stream mode reply routing#9608
fix(dingtalk): accept oapi.dingtalk.com webhook domain for stream mode reply routing#9608audanye-sudo wants to merge 1 commit into
Conversation
…dingtalk.com DingTalk Stream SDK returns session webhooks using oapi.dingtalk.com domain, but the SSRF validation regex only accepted api.dingtalk.com. This caused all reply routing via session webhooks to silently fail in stream mode. Also fixes docker.md version check command to use `docker exec` instead of `docker run` which would start a new container.
|
good change |
|
Hey folks 👋 Just want to give some context on this PR and the other two DingTalk PRs I'm submitting together (#9609, #9610), since DingTalk might not be familiar to everyone here. What is DingTalk?DingTalk (钉钉) is basically the "Slack/Teams of China" — it's an enterprise communication platform by Alibaba with 700M+ registered users and is the dominant workspace app across Chinese enterprises. Think of it as Slack + Zoom + HR tools + low-code platform all in one. For Hermes Agent, DingTalk support means opening up the bot to a massive user base in the Chinese market. Current situation: DingTalk integration is completely brokenRight now, the DingTalk adapter in Hermes has two blocking bugs that make it literally unusable end-to-end:
These two together mean: users who try to set up DingTalk today will see the bot "online" but it won't respond to anything. That's a pretty bad first impression. This specific PR is the simpler of the two fixes — just a one-line regex change to accept both |
RuckVibeCodes
left a comment
There was a problem hiding this comment.
[gus-first-pass] fix(dingtalk): accept oapi.dingtalk.com webhook domain for stream mode reply routing - Clear fix, no issues found.
Jiangxuejian
left a comment
There was a problem hiding this comment.
This works on my WSL2. (Hermes Agent v0.9.0 (2026.4.13))
Summary
DingTalk Stream SDK returns
sessionWebhookURLs using theoapi.dingtalk.comdomain, but the current SSRF validation regex (_DINGTALK_WEBHOOK_RE) only acceptsapi.dingtalk.com. This causes all reply routing via session webhooks to silently fail when running in stream mode — messages are received but replies never reach the user.Root Cause
The webhook validation regex at
gateway/platforms/dingtalk.py:57was:DingTalk's Stream SDK actually returns webhooks like:
The
oapi.dingtalk.comdomain is the legacy but still actively used Open API endpoint, whileapi.dingtalk.comis the newer endpoint. Both are legitimate DingTalk domains.Fix
Updated the regex to accept both domains:
This is a minimal, targeted fix — no behavioral change for
api.dingtalk.comwebhooks; onlyoapi.dingtalk.comis additionally accepted.Additional Fix
Fixed the Docker troubleshooting docs (
website/docs/user-guide/docker.md): the version check command useddocker runwhich spins up a new container instead of checking the running one. Corrected todocker exec hermes hermes version.Commits
fix(dingtalk): accept oapi.dingtalk.com webhook domain alongside api.dingtalk.comgateway/platforms/dingtalk.py,website/docs/user-guide/docker.mdTest Plan
https://api.dingtalk.com/...andhttps://oapi.dingtalk.com/...oapi.dingtalk.comsession webhooksdocker execcorrectly queries the running containerRisk Assessment
Low risk — single regex change expanding the allowlist to include a legitimate DingTalk domain. No new dependencies, no architectural changes, no breaking changes.