fix(web): avoid crypto.randomUUID under non-secure-context deployments

[ZerxLabBot]

Repro

Self-hosted ghcr.io/zerx-lab/fluxdown-server deployed via Docker on a NAS (飞牛OS) and reached over plain http://<lan-ip>:17800 (no TLS in front). Logging into the FluxCloud panel throws crypto.randomUUID is not a function. (In 'crypto.randomUUID()', 'crypto.randomUUID' is undefined). Reproduced by transcribing cloudDeviceId() verbatim and invoking it against a crypto shim exposing only getRandomValues (no randomUUID) — exactly how Chromium/WebKit expose window.crypto on a non-secure origin per the WHATWG Secure Contexts spec (https://developer.mozilla.org/docs/Web/API/Crypto/randomUUID: "available only in secure contexts"). Output matched the reporter's pasted error text verbatim.

Cause

web/src/lib/cloud/session.ts's cloudDeviceId() called crypto.randomUUID() unconditionally to mint the panel's persistent FluxCloud device id. randomUUID() is spec-restricted to secure contexts (HTTPS, or http://localhost); the headless server binds 0.0.0.0:17800 with no built-in TLS, so a typical NAS/Docker deployment reached over plain LAN-IP HTTP is a non-secure origin and the method is simply absent on window.crypto. cloudDeviceId() runs on every FluxCloud login request (lib/cloud/client.ts's deviceInfo()), so login failed immediately.

Fix

• Add a local randomUuidV4() in web/src/lib/cloud/session.ts that builds an RFC 4122 v4 UUID from crypto.getRandomValues() (setting the version/variant bits per spec) — getRandomValues() carries no secure-context restriction, and is already the pattern used for components/settings/SecuritySettings.tsx's token generation.
• Swap cloudDeviceId()'s crypto.randomUUID() call for randomUuidV4().

Verification

bun x tsc -b --noEmit (web) — clean, no errors. bun run lint — unchanged pre-existing warnings only, session.ts not flagged. Ran 10,000 iterations of the new generator against both an insecure-context crypto shim (no randomUUID, matching the reported deployment) and the real environment crypto object: all outputs match the RFC 4122 v4 pattern (^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$) with zero collisions, and no exception is thrown under the insecure-context shim (previously threw TypeError: crypto.randomUUID is not a function, matching the report verbatim).

Fixes #204

[CLAassistant]

All committers have signed the CLA.

[zerx-lab]

Repro

Self-hosted ghcr.io/zerx-lab/fluxdown-server deployed via Docker on a NAS (飞牛OS) and reached over plain http://<lan-ip>:17800 (no TLS in front). Logging into the FluxCloud panel throws crypto.randomUUID is not a function. (In 'crypto.randomUUID()', 'crypto.randomUUID' is undefined). Reproduced by transcribing cloudDeviceId() verbatim and invoking it against a crypto shim exposing only getRandomValues (no randomUUID) — exactly how Chromium/WebKit expose window.crypto on a non-secure origin per the WHATWG Secure Contexts spec (https://developer.mozilla.org/docs/Web/API/Crypto/randomUUID: "available only in secure contexts"). Output matched the reporter's pasted error text verbatim.

Cause

web/src/lib/cloud/session.ts's cloudDeviceId() called crypto.randomUUID() unconditionally to mint the panel's persistent FluxCloud device id. randomUUID() is spec-restricted to secure contexts (HTTPS, or http://localhost); the headless server binds 0.0.0.0:17800 with no built-in TLS, so a typical NAS/Docker deployment reached over plain LAN-IP HTTP is a non-secure origin and the method is simply absent on window.crypto. cloudDeviceId() runs on every FluxCloud login request (lib/cloud/client.ts's deviceInfo()), so login failed immediately.

Fix

• Add a local randomUuidV4() in web/src/lib/cloud/session.ts that builds an RFC 4122 v4 UUID from crypto.getRandomValues() (setting the version/variant bits per spec) — getRandomValues() carries no secure-context restriction, and is already the pattern used for components/settings/SecuritySettings.tsx's token generation.
• Swap cloudDeviceId()'s crypto.randomUUID() call for randomUuidV4().

Verification

bun x tsc -b --noEmit (web) — clean, no errors. bun run lint — unchanged pre-existing warnings only, session.ts not flagged. Ran 10,000 iterations of the new generator against both an insecure-context crypto shim (no randomUUID, matching the reported deployment) and the real environment crypto object: all outputs match the RFC 4122 v4 pattern (^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$) with zero collisions, and no exception is thrown under the insecure-context shim (previously threw TypeError: crypto.randomUUID is not a function, matching the report verbatim).

Fixes #204

review

[ZerxLabBot]

PR is ready for review as-is — CLA signed, typecheck/lint clean, no outstanding changes requested.

[zerx-lab]

@ZerxLabBot #179 也是同样问题，检查同类问题一起关闭

[ZerxLabBot]

Confirmed: #179 is the same bug (crypto.randomUUID is not a function, same Docker/plain-HTTP LAN-IP deployment pattern — screenshot in #179 shows the identical error string). No code change needed beyond #205, which already fixes the shared root cause in web/src/lib/cloud/session.ts's cloudDeviceId(). Searched the tracker for other reports of this error (randomUUID is not a function, web异常, crypto, Something went wrong) — no other matches found; #179 is the only duplicate.

#179 should be closed as duplicate of #204 once #205 merges.