Summary
When an sshx session is embedded in a cross-origin <iframe> and the browser blocks third-party storage/cookies, the app fails to start and renders a blank page. The client appears to read localStorage unconditionally at startup; in that context the access throws and crashes initialization.
Environment
- Chromium-based browser with third-party cookies/storage blocked (now a common default), or any top-level context with an opaque origin.
- sshx session embedded via
<iframe src="https://sshx.io/s/...#key"> from a different origin.
Steps to reproduce
- Serve a page on origin A containing
<iframe src="https://sshx.io/s/XXXX#KEY">.
- Block third-party cookies/storage in the browser (or embed from a
data: URL, which has an opaque origin).
- Open the page.
Expected
The "Welcome! — what should we call you?" join screen renders (as it does when third-party storage is allowed).
Actual
Blank iframe. Console shows:
SecurityError: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
Notes / suggested fix
The site is otherwise iframe-friendly (no X-Frame-Options / CSP frame-ancestors), and it works fine in an iframe when storage is allowed. The only issue is that localStorage (and probably sessionStorage) access isn't guarded. Wrapping storage access in a try/catch with an in-memory fallback — or feature-detecting availability before use — would let the app start (perhaps degrading "remember my name" gracefully) instead of crashing.
Found while embedding sshx in splitr, a split-screen iframe viewer.
Summary
When an sshx session is embedded in a cross-origin
<iframe>and the browser blocks third-party storage/cookies, the app fails to start and renders a blank page. The client appears to readlocalStorageunconditionally at startup; in that context the access throws and crashes initialization.Environment
<iframe src="https://sshx.io/s/...#key">from a different origin.Steps to reproduce
<iframe src="https://sshx.io/s/XXXX#KEY">.data:URL, which has an opaque origin).Expected
The "Welcome! — what should we call you?" join screen renders (as it does when third-party storage is allowed).
Actual
Blank iframe. Console shows:
Notes / suggested fix
The site is otherwise iframe-friendly (no
X-Frame-Options/ CSPframe-ancestors), and it works fine in an iframe when storage is allowed. The only issue is thatlocalStorage(and probablysessionStorage) access isn't guarded. Wrapping storage access in atry/catchwith an in-memory fallback — or feature-detecting availability before use — would let the app start (perhaps degrading "remember my name" gracefully) instead of crashing.Found while embedding sshx in splitr, a split-screen iframe viewer.