Login fails in Firefox: CSP blocks eval() in oidc-client-ts, "No matching state found in storage"

[maki-ikam]

Initial Checklist

• I understand this is a bug report and questions should be posted in the Community Discussions
• I searched issues and couldn't find anything (or linked relevant results below)

Bug Description

The OIDC login flow fails in Firefox. After successful authentication callback, the page hangs indefinitely at "Sie werden eingeloggt" / "You are being signed in".

The browser console shows two related errors:

1. **CSP violation:**Source: PortalTarget.vue_vue_type_script_lang-*.mjs

2. **OIDC error (consequence of Branding #1):**This is incompatible with Firefox's strict CSP enforcement when oidc-client-ts (or its wrapper) uses eval() / new Function() internally to process tokens.

Steps to Reproduce

1. Self-hosted OpenCloud 4.0.5 with internal IDP (Konnect)
2. Open OpenCloud URL in Firefox (latest stable)
3. Click login, enter credentials
4. After successful auth callback, page redirects to /web-oidc-callback?code=...&state=...
5. Page shows "Sie werden eingeloggt" and hangs forever

Works fine in Chrome, Edge (different CSP enforcement).

Expected Behavior

Login should complete and redirect to the main UI in any modern browser, including Firefox.

Workaround

Override the default CSP via PROXY_CSP_CONFIG_FILE_LOCATION with a custom csp.yaml that adds 'unsafe-eval' to script-src.

This works, but requires every Firefox-using OpenCloud admin to deploy this workaround. It also reduces the security posture of the default deployment.

Suggested Fix

Either:

1. Refactor the oidc-client-ts wrapper code to avoid eval() / new Function() (preferred)
2. Add 'unsafe-eval' to the default CSP shipped with OpenCloud (security tradeoff)
3. Document the Firefox incompatibility prominently and document the workaround in the official docs

Environment

• OpenCloud version: 4.0.5 (production)
• Browser: Firefox (latest stable)
• IDP: internal Konnect (default)
• Reverse proxy: Tailscale Serve (HTTPS termination)
• Affects: any Firefox user, any deployment using the default CSP

[JammingBen]

I don't think the CSP logs are related to your issue. This is a known thing, apparently Firefox reports simple references to eval via this log, even though it never gets called.

Where exactly does it state No matching state found in storage? In the UI, the console, or in a network response? More detailed information about failed requests and the exact console error would be helpful.

Either way, the error message sounds like a local browser storage issue. Did you try clearing all website data (cache, cookies, local & session storage)? And logging in in a private window?

[maki-ikam]

Thanks for getting back to me — fair point about the CSP log being a possible red herring. But there are some additional data points that I think rule out a pure browser storage issue:

Same error in Chrome and Edge — not Firefox-specific

A second user (different physical device, never logged in before) also got stuck at the "Sie werden eingeloggt" screen — in Chrome AND Edge, not just Firefox. Same console error trail. So this isn't a Firefox-only quirk.

Storage was reset, error persisted

Before applying the workaround we tried (in this order):

• Cleared all cookies + Local Storage + Session Storage for the domain via DevTools
• Tested in Firefox private window
• Tested in fresh Chrome profile
• Tested in fresh Edge profile

The "No matching state found in storage" error reproduced in all of them.

The CSP workaround fixed it immediately

After mounting a custom csp.yaml via PROXY_CSP_CONFIG_FILE_LOCATION that adds 'unsafe-eval' to script-src (everything else identical to default), login worked on the first try in all three browsers. No other changes.

That's a strong correlation — if it were truly a local storage issue, adding unsafe-eval to the CSP shouldn't fix anything.

Where the errors appear

All in the browser console, not the network tab:

Content-Security-Policy: Die Einstellungen der Seite haben die Ausführung eines JavaScript-Evals (script-src) blockiert, da es gegen folgende Direktive verstößt: "script-src 'self' 'unsafe-inline'" (es fehlt 'unsafe-eval')
Source: PortalTarget.vue_vue_type_script_lang-BtcHSdI5.mjs:62
[OidcClient] readSigninResponseState: Error: No matching state found in storage
readSigninResponseState PortalTarget.vue_vue_type_script_lang-BtcHSdI5.mjs:83
processSigninResponse PortalTarget.vue_vue_type_script_lang-BtcHSdI5.mjs:83
_signinEnd PortalTarget.vue_vue_type_script_lang-BtcHSdI5.mjs:83
_signinEnd index.html-CGFTrQAi.mjs:37
signinRedirectCallback PortalTarget.vue_vue_type_script_lang-BtcHSdI5.mjs:83
signInCallback index.html-CGFTrQAi.mjs:37
runtimeLoaded /web-oidc-callback?code=...&state=...:175
error during authentication: Error: No matching state found in storage

The HTTP request to /web-oidc-callback itself returns 200 OK — the failure is purely client-side after the callback URL loads.

Possible mechanism

I'm guessing oidc-client-ts (or its wrapper) has a code path that uses eval() or new Function() before writing the state to sessionStorage — so when CSP blocks the eval, an exception is thrown silently before the state is persisted. The "No matching state" error on callback would be the visible symptom of that earlier silent failure. Just speculation, but it matches the observed behavior.

Environment

• OpenCloud 4.0.5 — also confirmed on 4.0.6 (workaround still required)
• Reverse proxy: Tailscale Serve (HTTPS termination, plain HTTP to OpenCloud)
• IDP: internal Konnect
• Affected browsers tested: Firefox, Chrome, Edge (all latest stable)