Dynamic ES-module imports lose credentials behind Cloudflare Access / SSO cookie (white screen)

[wegelcloud]

Symptom

NiceGUI apps served behind an SSO layer that uses cookies (e.g. Cloudflare Access, AWS Cognito with cookie mode, Tailscale Funnel with Access) render a blank page. The root HTML comes through fine, but every request to /_nicegui/<version>/components/<hash>/*.js returns a 302 Redirect to the SSO login page instead of the actual JS module.

The browser's Network tab shows:

• GET / → 200 (HTML, contains <script type="module" src="/_nicegui/3.9.0/components/.../quasar.umd.prod.js">)
• GET /_nicegui/3.9.0/components/<hash>/html.js → 302 → login page (HTML)
• JS fails to evaluate: Uncaught SyntaxError: Unexpected token '<'

Root cause

Dynamic <script type="module" src=...> and dynamic import() fetches are treated as cross-origin credentialless fetches by default (no cookies sent) unless explicitly marked with crossorigin="use-credentials" or credentials: 'include'.

Cookie-based SSO reverse proxies (CF Access, Cognito cookie mode, Tailscale Funnel with Access policy) require the SSO session cookie on every request — including static JS asset requests from inside the same origin. Without cookies, the proxy responds with a 302 to its login endpoint, which the browser then tries to parse as JS.

Reproduction

1. Deploy any NiceGUI 3.x app (3.4+ is fine, this is about module-import-fetch semantics, not a NiceGUI version regression — but 3.9+ makes it worse because more components are lazy-loaded as modules).
2. Put it behind Cloudflare Access with an email-based policy (or any auth-required application).
3. Log in once, so the browser holds the CF_Authorization cookie.
4. Open the NiceGUI app → blank page.
5. DevTools → Network → filter _nicegui → every .js is 302 to /cdn-cgi/access/login/....

Workaround we're using

Pinned NiceGUI to 3.4.1 where inline-evaluated bootstrap minimizes the module-fetch surface (not a real fix — same class of bug, just less visible). Upgrade to 3.9 is blocked for us.

Suggested fix

Render the script tags with crossorigin="use-credentials":

<script type="module" crossorigin="use-credentials" src="/_nicegui/.../html.js"></script>

And for any internal import() calls, use the options form:

import(/* webpackIgnore: true */ url, { credentials: 'include' })

(when that's supported — or simpler: rely on the same-origin policy and don't add crossorigin attribute at all, but the current behavior seems to add it without use-credentials).

Looking at the source, the generated <script> tags appear to come from the page-template renderer (likely nicegui/templates/index.html or the dynamic router in client.py). A single template-level change + a documentation note would fix the whole class of cookie-SSO deployments (which is the majority of enterprise / internal-tool NiceGUI use cases).

Related

• MDN: CORS — crossorigin attribute
• HTML spec: <script type="module"> fetch mode defaults to "same-origin" but credentials default to "omit" unless crossorigin attribute is present

Environment

• NiceGUI 3.9.0 (also reproduced with 3.4.1 for different components)
• Python 3.12
• Browser: Chrome / Safari
• Reverse proxy: Cloudflare Tunnel + Cloudflare Access (cookie-based SSO)
• Hit rate: 100% white-screen for any authenticated user; unauthenticated hits the login wall at /, so the bug only manifests for returning authenticated users where the browser has the cookie but every module-fetch is still treated as credentialless.

Happy to contribute a PR if you're open to the template change. Let me know the preferred approach — crossorigin="use-credentials" on the generated tags, or documenting the expected reverse-proxy setup.

[falkoschindler]

Thanks for the detailed write-up, @wegelcloud — this is a helpful report. Browser fetch/credentials semantics behind SSO proxies is a bit outside my comfort zone, so I asked Claude to help me think this through. A few things I'd like to verify before changing the template, because the fix isn't risk-free.

On the root-cause claim. Since the 2019 spec update, <script type="module"> and <link rel="modulepreload"> without a crossorigin attribute fetch with credentials: "same-origin" — i.e., cookies are sent for same-origin requests. That's been the behavior in Chrome 79+, Firefox 68+, and Safari 14.1+. The /_nicegui/... URLs in our template are relative (same-origin), so cookies should already be attached on a modern browser. This doesn't match what you're seeing, so something else is going on. A few things that would help narrow it down:

• In DevTools → Network → the failing html.js request → Cookies tab: is CF_Authorization listed under Request Cookies? If not, it's a cookie-scoping issue (SameSite, path, domain) rather than a credentials-mode issue.
• Exact Chrome/Safari version.
• Is the page served from the exact same origin (scheme + host + port) as the /_nicegui/... assets, or is there any host/subdomain difference introduced by the tunnel?
• Does a plain <script defer src="/_nicegui/.../nicegui.js"> (non-module) request in the same session also 302, or only the module requests? That distinction would confirm whether credentials-mode is really the variable.

On the proposed fix. crossorigin="use-credentials" has two effects, not one:

1. Credentials mode becomes "include" (what you want).
2. Request mode becomes CORS — the server must respond with Access-Control-Allow-Origin: <exact-origin> (not *) and Access-Control-Allow-Credentials: true, or the browser rejects the response.

For same-origin requests that weren't previously in CORS mode, that's a net-new requirement. It would break deployments that serve assets from a path where the reverse proxy doesn't echo the origin back. That's why I'd rather understand why the same-origin default isn't working in your setup before globally switching to use-credentials.

Likely easier workaround in the meantime. Cloudflare Access supports per-application bypass rules; most SSO-wrapped deployments exempt static asset paths (/_nicegui/* here) from auth since they don't contain user data. That's the standard pattern for sites behind Access, and it sidesteps the cookie question entirely. Worth trying if you haven't — it would also confirm the diagnosis.

Happy to revisit the template change if we can pin down a scenario where a modern browser genuinely drops cookies on a same-origin module fetch — that would be a real bug worth fixing at the template level.