fix: preview PDFs via blob URL instead of a remote iframe

[shanzez]

Summary

Fixes #1.

EmbeddedPDF iframes getFileUrl(...). That is blank when the file server is cross-origin (desktop loadFile origin, cloud dl.huly.app vs huly.app): the session cookie is not sent, and X-Frame-Options: SAMEORIGIN (or our nginx equivalent) refuses the frame.

This follows the existing files-preview workaround: download the file with Authorization: Bearer (datalake already accepts it; cors() default allows the preflight) and iframe a same-origin blob: URL. Tokens stay out of the URL. pdf.js is not required.

Same-origin self-host still works: the fetch is same-origin, so cookies go with it.

What changed

• EmbeddedPDF.svelte — fetch the remote file (Bearer token when the caller has one), createObjectURL, iframe that. blob: / data: srcs are used as-is so HTML preview does not re-download. Aborts and revokes on src change / unmount.
• PDF viewers — pass presentation.metadata.Token.
• EmbeddedHTML / DOCX preview — same path, so converted HTML also authenticates when the file is on datalake.

Why not ?token= or pdf.js

• Datalake already reads Authorization and cookies (extractToken). Putting the token in the URL is worse and unnecessary.
• Cookie Set-Cookie on the datalake domain was never implemented; JS document.cookie cannot set it cross-origin.
• pdf.js would work, but it is a large dependency for a problem the blob-URL workaround already solves.

Credit: Exaviz team.

[haiodo]

It was not updated for a while yep.

[haiodo]

Actually self hosted versions are path based and use same origin, it was a Huly global deployment used separate services. Also datalake in case of path based hosting support cookie based auth, so potentially token will not be required. @aonnikov may comment.

[shanzez]

btw, I am running this on prem right now.

[shanzez]

@haiodo you are right about the browser case, and I should have said so in July instead of the one-liner I left. Apologies for the long silence on my own PR.

Path-based self-hosting is same-origin, and if datalake accepts the session cookie there, the ?token= query param buys nothing for a browser client. I am happy to drop it for that path.

The case it does not cover is the desktop app. The desktop front is loaded from disk — desktop/src/main/start.ts:282, await mainWindow.loadFile(containerPagePath) — so the renderer origin is local no matter how the server is hosted. Every request to the workspace is cross-origin from there, and a credentialed fetch is additionally blocked because the file server answers Access-Control-Allow-Origin: * with no Access-Control-Allow-Credentials. So cookie auth cannot be the only mechanism for desktop. That is the part of the token argument I would like to keep.

Proposal, if agreeable: derive the file URL's origin and only append the token when it differs from location.origin. Path-based browser deployments then use the cookie and never see a token in a URL; desktop still works. Small change on top of what is here, and I will push it.

Two corrections to my own PR description while I am here, because both were stated more strongly than what I actually verified:

• The blank PDF I originally chased on our own on-prem instance turned out to be our own nginx sending X-Frame-Options: SAMEORIGIN on the file route. That is a same-origin path-based deployment, so it argues the iframe path is fragile to a proxy header rather than to an origin split. It supports the change, but not for the reason I gave.
• I claimed WebKit does not render PDF-in-iframe at all. I have not re-tested that on current Safari and I am not going to defend it until I have. Treat the desktop origin and the header fragility as the case for this PR.

Still current as of today: the branch is mergeable/clean against develop, and packages/ui/src/components/EmbeddedPDF.svelte on develop still uses the native iframe, so nothing here has been overtaken.

@aonnikov you were tagged on 2026-07-10 and I do not think this reached you. The one question that decides the shape: does pod-datalake accept cookie auth for a path-based self-host today, or is that a "should work" rather than a "does work"?

Tell me whether you want the origin-gated token or the token removed outright and I will turn it around this week.

[aonnikov]

@shanzez I somehow overlooked this question.
pod-datalake is able to read token from both Authorization and Cookies headers. The main issue was with passing the token via cookies. As long as it was different origin (dl.huly.app vs huly.app), we would need to have cookies set somehow for datalake domain. One of ideas was to call an API method on pod-datalake API to let it set the cookie, but we never implemented this. Current implementation sets the token from the JS code, but it works only when pod-datalake is on the same origin.

For files preview there was a workaround implemented, instead of embedding PDF documents via URL we download them and embed via blob URL.

[shanzez]

@aonnikov thanks — that last sentence was the steer.

We dropped pdf.js and ?token=. EmbeddedPDF now does the existing files-preview workaround: fetch with Authorization: Bearer (datalake already reads it from that header; default cors() allows the preflight; we do not send credentials, so Access-Control-Allow-Origin: * is fine) and iframe a blob: URL. Same-origin self-host still sends cookies on that fetch. Desktop still works because the renderer can fetch with Authorization even though loadFile makes the page origin local.

Pushed over this PR.