gitea-admin/dingMCP
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 9 Wiki Activity

fix: route cross-device OAuth through device flow
CI / Client installer (macos-latest) (push) Canceled after 0s
Details
CI / Client installer (ubuntu-latest) (push) Canceled after 0s
Details
CI / Client installer (windows-latest) (push) Canceled after 0s
Details
CI / test (22) (push) Canceled after 0s
Details
CI / test (24) (push) Canceled after 0s
Details
CI / release-smoke (push) Canceled after 0s
Details

Browse Source
This commit is contained in:
gitea-admin
2026-08-19 02:05:07 +00:00
parent 7e2a01c913
commit 2aa78aebd9
12 changed files with 39 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/dingtalk-approval/SKILL.md
+2 -2
View File
@@ -9,11 +9,11 @@ Use only the `dingtalk-approval` MCP tools. DingTalk OA and XFT use the same gat
## Login and first run
Use the host's native remote-MCP OAuth flow by default. When the remote server requests authentication, let the host open or present the authorization URL and have the user authorize it personally. Never claim that a link was pushed through another channel. After OAuth succeeds, make one read-only `approval_list_todos` call with `source=all` and `limit=1`; both DingTalk OA and XFT must be available before reporting setup complete.
Use the host's native remote-MCP OAuth flow when the user can complete its registered callback. If the redirect URI uses `127.0.0.1` or `localhost`, the user must open the authorization page on the same device that runs the Agent. An SSH, headless, Messenger, phone, or other cross-device interaction cannot complete that loopback callback and must use the local STDIO Bridge device-code flow instead. If the interaction topology is unknown during installation, ask only whether the user will open the page on the Agent's device. When native OAuth is suitable, let the host open or present the authorization URL and have the user authorize it personally. Never claim that a link was pushed through another channel. After OAuth succeeds, make one read-only `approval_list_todos` call with `source=all` and `limit=1`; both DingTalk OA and XFT must be available before reporting setup complete.
When a successful response contains `onboarding.firstRun=true`, show its short examples and write-safety note once. Do not execute an example automatically.
Only hosts that cannot use remote Streamable HTTP MCP or standard OAuth should use the optional local STDIO Bridge. In that compatibility mode, handle the installer's `postInstall` immediately. If it contains `authChallenge.directUrl`, copy the complete clickable URL into the current reply. If the link expires, call `approval_login`; if the connector is not loaded yet, run the returned `loginCommand`. Never reinstall merely to renew a link, read Bridge state files, or render QR images as ASCII. One successful gateway login covers both sources.
Hosts that cannot use remote Streamable HTTP MCP or standard OAuth, and cross-device users who cannot reach a host loopback callback, should use the optional local STDIO Bridge. In that compatibility mode, handle the installer's `postInstall` immediately. If it contains `authChallenge.directUrl`, copy the complete clickable URL into the current reply; the user may open this device-code page on another device. If the link expires, call `approval_login`; if the connector is not loaded yet, run the returned `loginCommand`. Never reinstall merely to renew a link, read Bridge state files, or render QR images as ASCII. One successful gateway login covers both sources.
## Review and process