fix(gateway/dingtalk): allow oapi.dingtalk.com webhook + correctness fixes#8957
Closed
sputnicyoji wants to merge 1 commit into
Closed
fix(gateway/dingtalk): allow oapi.dingtalk.com webhook + correctness fixes#8957sputnicyoji wants to merge 1 commit into
sputnicyoji wants to merge 1 commit into
Conversation
…fixes A blocking SSRF-regex bug plus a handful of small correctness issues found in the DingTalk adapter: - The SSRF origin check accepts only `api.dingtalk.com`, but DingTalk's group-chat session webhooks come from `oapi.dingtalk.com`. In any real group/org deployment every reply fails with "No session_webhook available." Broaden the regex to `https://(?:o?api)\.dingtalk\.com/`. - FIFO eviction of `_session_webhooks` pops the head even when the incoming `chat_id` is already in the dict — silently evicting a still-valid entry. Skip eviction when the key is a rewrite. - `get_chat_info` inferred `"group"` from the string `"group" in chat_id.lower()`, which is wrong for every real `cidXXXX==` DingTalk conversation id. Track an explicit `_chat_types` map populated from `conversation_type` during inbound. - `send()` silently truncated long replies at `MAX_MESSAGE_LENGTH`; log a `warning` so the truncation is visible in operator logs. - Name the stream task (`<platform>-stream`) so it shows up usefully in `asyncio.all_tasks()` dumps. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This was referenced Apr 13, 2026
Contributor
Author
|
Thanks for the follow-up and for landing the fix via #11471 — glad the issue is now resolved on main. Appreciate the maintenance work. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A blocking SSRF-regex bug plus a handful of small correctness issues in the DingTalk adapter:
api.dingtalk.com, but DingTalk's group-chat session webhooks come fromoapi.dingtalk.com. In any real group/org deployment every reply fails with"No session_webhook available. Reply must follow an incoming message.". Broaden the regex tohttps://(?:o?api)\.dingtalk\.com/._session_webhookspopped the head even when the incomingchat_idwas already in the dict — silently evicting a valid entry on rewrite. Skip eviction when the key is a rewrite.get_chat_infouses an authoritative chat-type map. Previous heuristic ("group" in chat_id.lower()) never matches realcidXXXX==DingTalk conversation ids. Track_chat_typespopulated fromconversation_typeduring inbound.send()logs a warning when truncating atMAX_MESSAGE_LENGTHinstead of silently clipping.<platform>-stream) so it shows up usefully inasyncio.all_tasks()dumps.Test plan
@botwith a realoapi.dingtalk.comsession webhook now replies successfully.Builds cleanly on top of #8954 (SDK 0.24 compat) or on its own against
main.