WebUI authentication broken through Cloudflare proxy with strict browsers (e.g. Librewolf)

[Tiritibambix]

Hi,

I recently migrated from tomsquest/docker-radicale to the official ghcr.io/kozea/radicale:stable image and ran into an issue with the WebUI getting stuck on the loading spinner when accessed through a reverse proxy (Nginx Proxy Manager) with Cloudflare proxy enabled.

After a lot of debugging, I found that the new WebUI introduced in 3.7.0 handles authentication via XHR requests in JavaScript, whereas the older WebUI triggered a native browser Basic Auth popup. This change in behavior causes two related issues.

First, when Cloudflare proxy is active, it modifies response headers in transit, stripping or altering the CORS and WWW-Authenticate headers that the WebUI JavaScript needs to handle the 401 response and display the login form. This results in the WebUI being stuck on the spinner indefinitely. Adding Access-Control-Allow-Origin and related headers in the [headers] section of the Radicale config partially helps, but Cloudflare still interferes.

Second, privacy-hardened browsers like Librewolf are stricter about XHR-based Basic Auth challenges than standard Firefox or Chromium. With the old WebUI (native browser popup), Librewolf worked fine. With the new JS-based auth, Librewolf gets stuck on the spinner even when Cloudflare is bypassed — unless specific CORS headers are explicitly set in Radicale's config.

Disabling the Cloudflare proxy (DNS only mode) and adding the CORS headers to the Radicale config fixes everything for standard browsers. Librewolf works too once Cloudflare is out of the picture.

This might be worth documenting in the reverse proxy section, specifically that the new WebUI requires proper CORS headers and that Cloudflare proxy mode can break the authentication flow. A note about privacy-hardened browsers would also be helpful.

For reference, here is the [headers] config that made things work:

[headers]
Access-Control-Allow-Origin = https://your-domain.com
Access-Control-Allow-Methods = GET, POST, PUT, DELETE, PROPFIND, PROPPATCH, MKCALENDAR, MKCOL, REPORT, OPTIONS
Access-Control-Allow-Headers = Authorization, Content-Type, Depth, If-Match, If-None-Match
Access-Control-Expose-Headers = DAV, content-type, WWW-Authenticate

Thanks for the great work, the sharing feature is exactly what I needed.

[pbiering]

After a lot of debugging, I found that the new WebUI introduced in 3.7.0 handles authentication via XHR requests in JavaScript, whereas the older WebUI triggered a native browser Basic Auth popup. This change in behavior causes two related issues.

Hmm, my request to @maxberger was only to move credentials from URL into header to avoid that e.g. proxies can simply log them and browser are displaying them.

@maxberger - can you add the suggestion headers on next PR?

[maxberger]

Will take this one. That said, I would like to wait for #2085 to have reached a somewhat stable state before adding the actual documentation.

@Tiritibambix : First of all, thank you so much for your debugging efforts! I was unaware of the extra things cloudflare does to the headers; just to clarify: Are these issues replicable with just Librewolf? Then I can test locally. Also, have you tried upload/download of a collection? Those can unfortunately have other side-effects. Let me know if they work fine in your setup.

I see two needed actions here:

1. You should never get stuck on the spinner. If there are cors or other errors, they should show up in the UI
2. The documentation needs to be updated.

Thank you for reporting this!

[Tiritibambix]

I’m sorry @maxberger , I’m not able to run those tests at the moment.

However, you should be able to reproduce the issue with LibreWolf as long as you’re using npm and a Cloudflare proxy.

I’ll get back to you as soon as I’ve been able to run the tests you asked for.

[pbiering]

@Tiritibambix - were you able to test?

[maxberger]

I tried replicating this again, but since I do not have cloudflare I cannot reproduce. Checks with Librewolf work fine for me, both locally and remotely; I am unable to replicate the issue.

I would still add your documentation snippet to the proxy configuration once we have the new documentation ready, so right now this is blocked on #2085

[maxberger]

In addition, I also created a new setting which would fall back to browser-based login:
#2145
You can try and see if this one helps (planned for 3.7.4)