Skip to content

Fix crypto.randomUUID crash over plain HTTP (non-secure context)#149

Merged
pufit merged 1 commit into
mainfrom
pufit/fix-randomuuid-nonsecure
Jun 24, 2026
Merged

Fix crypto.randomUUID crash over plain HTTP (non-secure context)#149
pufit merged 1 commit into
mainfrom
pufit/fix-randomuuid-nonsecure

Conversation

@pufit

@pufit pufit commented Jun 24, 2026

Copy link
Copy Markdown
Member

Accessing the web UI over plain HTTP via a LAN host (e.g. http://192.168.x.x:8900 or a .local name) crashes with:

TypeError: crypto.randomUUID is not a function

Cause

crypto.randomUUID() is only exposed in secure contexts — HTTPS or http://localhost. Over plain HTTP to any other host, crypto.randomUUID is undefined, so the two call sites that generate client-side ids throw.

Fix

New web/src/utils/randomUUID() helper with graceful degradation:

  1. native crypto.randomUUID() when available (secure context),
  2. else an RFC 4122 v4 UUID built from crypto.getRandomValues() — which is available in non-secure contexts,
  3. else Math.random() as a last resort (these ids are only client-side keys, never security-sensitive).

Wired into the two existing usages:

  • stores/chatStore.ts — virtual session id
  • components/Chat/ChatInput.tsx — attachment id

These were the only crypto.randomUUID uses; no crypto.subtle usage exists that would hit the same restriction.

Testing

  • npm run build passes (tsc + vite).

Generated by Nerve

crypto.randomUUID() is only available in secure contexts (HTTPS or
localhost), so accessing the UI over plain HTTP via a LAN host throws
"TypeError: crypto.randomUUID is not a function". Add a randomUUID()
helper that falls back to a v4 UUID built from crypto.getRandomValues()
(available in non-secure contexts), then Math.random() as a last resort.
Use it in chatStore and ChatInput.
@pufit pufit merged commit 8970aa3 into main Jun 24, 2026
2 checks passed
pufit pushed a commit that referenced this pull request Jun 27, 2026
)

navigator.clipboard is only exposed in secure contexts (HTTPS or
http://localhost). When the UI is accessed over plain HTTP via a LAN
hostname/IP, or behind a proxy without a trusted cert, the entire
clipboard object is undefined and any call throws
'TypeError: Cannot read properties of undefined (reading writeText)'.

Two affected call sites:
- web/src/components/Chat/CodeBlock.tsx — the per-code-block Copy button
- web/src/pages/ChatPage.tsx — Cmd+Shift+C 'copy last response' shortcut

Both silently failed without surfacing any UI feedback.

Add a shared copyToClipboard helper that prefers navigator.clipboard
when available and falls back to a hidden off-screen <textarea> +
document.execCommand('copy'). execCommand is deprecated but still
implemented in every browser we care about.

Mirrors the same non-secure-context fallback pattern already used in
utils/uuid.ts (introduced by #149).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant