[Bug/UX] HTTP 部署下复制密钥仅提示“复制失败”，缺少降级处理和原因提示

[Kinda2419]

问题描述

在 CC Hub「用户管理」中创建用户和密钥后，点击「创建成功」弹窗里生成密钥右侧的复制按钮，页面只提示「复制失败」，无法通过按钮复制，只能手动选中密钥文本。

历史 Issue #407 已说明：HTTP 页面可能因浏览器安全限制无法使用 Clipboard API，并建议改用 HTTPS。本 Issue 不重复讨论该限制本身，而是反馈当前失败时的产品行为：

1. 错误提示没有说明失败原因，也没有告诉用户应改用 HTTPS 或手动复制；
2. 没有可用的降级复制方案；
3. 密钥通常只在创建后完整展示一次，笼统失败提示容易造成密钥丢失或误操作。

复现步骤

1. 通过 HTTP 访问 CC Hub。
2. 进入「用户管理」并创建用户。
3. 在「创建成功」弹窗中点击生成密钥右侧的复制图标。
4. 查看页面提示和剪贴板内容。

实际结果

• 页面右下角仅显示「复制失败」；
• 密钥未写入剪贴板；
• 只能手动选中文本复制；
• 当前环境中每次均可复现。

预期结果

建议至少实现以下一种处理：

• Clipboard API 不可用或被拒绝时，尝试兼容性降级复制；
• 若无法降级，显示可操作的错误说明，例如：
  • 「当前 HTTP 环境不允许访问剪贴板，请改用 HTTPS」；
  • 「复制失败，请手动选择密钥文本复制」；
• 可考虑在失败后自动选中密钥文本，降低密钥丢失风险。

环境

• 部署协议：HTTP
• CC Hub 版本/构建号：暂未获取
• 浏览器及版本：暂未获取
• 操作系统：暂未获取
• 发生频率：每次

相关 Issue

• 用户管理里密钥复制失败 #407：用户管理里密钥复制失败

#407 通过「改用 HTTPS」解决并关闭；本 Issue 关注 HTTP 场景中的降级行为和错误提示是否可以改进。

证据说明

已保留包含「创建成功」弹窗、复制按钮和「复制失败」提示的截图。原图还包含用户名称及部分 Key 前后缀，因此未直接公开上传；如维护者需要，可以补充进一步裁剪和脱敏后的截图。

[github-actions]

Thank you for reporting this issue, and for the clear reproduction steps and the distinction from #407.

Analysis

Your diagnosis is correct. Over plain HTTP (non-localhost), the browser's async Clipboard API (navigator.clipboard.writeText) is blocked because the context is not "secure" (window.isSecureContext === false), so the call rejects. The relevant dialogs currently call that API directly, and on failure only show a generic "复制失败 / Copy failed" toast with no fallback and no explanation.

Potentially affected code

The dialogs that copy a freshly generated key all use the raw API directly, instead of the shared clipboard utility:

• src/app/[locale]/dashboard/_components/user/create-user-dialog.tsx:283 — the "创建成功" dialog copy handler (the one in this report). On failure it shows tCommon("copyFailed") (create-user-dialog.tsx:289), i.e. the generic common.copyFailed = "Copy failed" (messages/en/common.json:24).
• src/app/[locale]/dashboard/_components/user/add-key-dialog.tsx:55 — same pattern in the "add key" success dialog (add-key-dialog.tsx:61).
• src/app/[locale]/dashboard/_components/user/key-full-display-dialog.tsx:48 — the full-key display dialog (key-full-display-dialog.tsx:54).
• src/app/[locale]/dashboard/_components/user/key-row-item.tsx:251 — the per-row copy button (key-row-item.tsx:255).

A fallback already exists — it is just not wired into these dialogs

The codebase already has a shared utility that does exactly the graceful degradation you are asking for:

• src/lib/utils/clipboard.ts
  • copyTextToClipboard() (clipboard.ts:39) tries navigator.clipboard.writeText() first, and on failure (or when isClipboardSupported() reports an insecure context) falls back to tryCopyViaExecCommand() (clipboard.ts:14), which uses the legacy document.execCommand("copy"). The legacy API is not gated behind a secure context, so this fallback works on plain HTTP.
  • isClipboardSupported() (clipboard.ts:5) checks window.isSecureContext, so callers can also detect the HTTP situation up front.

Sibling components in the same directory already use this utility instead of the raw API, so there is an established pattern to follow:

• src/app/[locale]/dashboard/_components/user/key-list.tsx:130 — const success = await copyToClipboard(fullKey); (and it tracks clipboardAvailable via isClipboardSupported() at key-list.tsx:54).
• src/app/[locale]/dashboard/_components/user/key-list-header.tsx:241 — const success = await copyToClipboard(keyResult.generatedKey); (isClipboardSupported() at key-list-header.tsx:119).

The utility also has unit test coverage for the secure-context / fallback behavior in tests/unit/lib/utils/clipboard.test.ts.

Mapping to your three suggestions

1. Compatibility fallback when Clipboard API is unavailable/rejected — Already implemented in copyToClipboard(); the four dialogs above just need to call it instead of navigator.clipboard directly, matching key-list.tsx / key-list-header.tsx.
2. Actionable error message (e.g. "HTTP blocks clipboard, use HTTPS / copy manually") — Not yet present. The only related string is the generic common.copyFailed ("Copy failed"). A new i18n key (covering the 5 supported locales) describing the HTTP/secure-context cause would be needed, and surfaced when isClipboardSupported() is false or the fallback also fails. Note that even where the utility is used today, the "clipboard unavailable on HTTP" case is handled silently (no toast on failure) rather than with an explanatory message.
3. Auto-select the key text on failure — Not currently implemented anywhere. The key input is already readOnly with font-mono (create-user-dialog.tsx:322), and the full-key display already exposes a select-all class when visible (key-full-display-dialog.tsx:77), so selecting-on-failure would be a small addition on top of those elements.

To help confirm the diagnosis

• The exact dialog you hit — was it the "Create User" success dialog (the one with the green UserPlus icon and "创建成功"), or the "Add Key" success dialog? Both have the same bug, but it helps narrow the first fix.
• Browser and version, and whether you were on a localhost/LAN IP vs. a remote HTTP host (this confirms isSecureContext was indeed false).
• (Optional) The redacted screenshot you mentioned, if convenient.

No workaround is needed beyond what you already found (manually selecting the key text), and deploying over HTTPS removes the root cause as noted in #407 — but the points you raise about the failure UX (no fallback, no explanation, key-loss risk) are valid regardless.

---

Automated response from Claude AI