Repository navigation
Conversation
`crypto.randomUUID()` is only exposed in secure contexts. Over plain HTTP on a non-localhost host it is `undefined`, so every client-side call threw `TypeError: crypto.randomUUID is not a function`. `tabStore` is built at module scope, so the throw happened during hydration of /trino: SSR succeeded (Node has a global crypto) and the browser received 200, but the page stayed blank and nothing rendered. Add `randomUUID()` in `$lib/utils/uuid.js`, which keeps the native fast path and falls back to `crypto.getRandomValues()` (not secure-context gated), and use it at the four client-side call sites: - tab-store (fatal — module-scope init) - toast store - storage connection ids - upload entries Server-side code keeps using `node:crypto`. Adds unit tests for the fallback and a browser regression test that removes `crypto.randomUUID`, and documents the secure-context constraint in AGENTS.md. Note: this only fixes the crash. HTTP-only deployment remains inadvisable — Trino credentials travel as Basic auth, and the cookie `Secure` flag and SvelteKit `ORIGIN`/CSRF settings still need configuring for plain HTTP.
# Conflicts: # src/lib/storage/connection-storage.ts # src/lib/stores/tab-store.svelte.spec.ts # src/lib/stores/toast.svelte.ts
`crypto.randomUUID` is only exposed in secure contexts, so it is `undefined` over plain HTTP on a non-localhost host. The S3 file browser added in #208 mints ids on the client in four places that call it directly, which throws `TypeError: crypto.randomUUID is not a function`: - tabs: initial tab, added tab, restored tabs - downloads: job id per file - transfers: operation and job ids Route them through `randomUUID()` from `$lib/utils/uuid.js`, which keeps the native fast path and falls back to `crypto.getRandomValues()`. This is the same fix as the Trino tab store, toast store and upload entries already use. The existing storage specs use the real browser `crypto`, so they exercise the fast path and would not catch a regression. Extend the insecure-context regression spec to cover the new call sites. Both insecure-context specs are now merged into one file on purpose: browser-mode Vitest evaluates SvelteKit's SSR module runner once per run, and its first evaluation races under full-suite parallelism. Two files triggering that init gave the race two entry points, and the resulting `wrapDynamicImport` failure left a Vite error overlay on the shared page that then failed ~100 unrelated UploadModal specs. The download case also spies on `document.createElement`/`body.appendChild` instead of clicking a real anchor, since that anchor pointed at a manifest route and made the dev server evaluate its `+server.ts` module. Verified: reverting the four files makes all five storage assertions fail with the original TypeError. Full unit suite passes 2153/2153 across repeated runs.
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
1 participant
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.
crypto.randomUUID()is only exposed in secure contexts. Over plain HTTP on a non-localhost host it isundefined, so every client-side call threwTypeError: crypto.randomUUID is not a function.tabStoreis built at module scope, so the throw happened during hydration of /trino: SSR succeeded (Node has a global crypto) and the browser received 200, but the page stayed blank and nothing rendered.Add
randomUUID()in$lib/utils/uuid.js, which keeps the native fast path and falls back tocrypto.getRandomValues()(not secure-context gated), and use it at the four client-side call sites:Server-side code keeps using
node:crypto.Adds unit tests for the fallback and a browser regression test that removes
crypto.randomUUID, and documents the secure-context constraint in AGENTS.md.Note: this only fixes the crash. HTTP-only deployment remains inadvisable — Trino credentials travel as Basic auth, and the cookie
Secureflag and SvelteKitORIGIN/CSRF settings still need configuring for plain HTTP.