Safari UI

[sylwesterdigital]

On Safari Version 18.1.1 (20619.2.8.11.12) - the website looks like this

Consoloe log:

[Error] Failed to load resource: the server responded with a status of 400 () (index.css, line 0)
[Error] Failed to load resource: the server responded with a status of 400 () (index.js, line 0)
[Warning] Couldn't find translation key index.code (indexBootstrap-x4z20TUka3k.min.js, line 4)

[JohnMcLear]

No it doesn't.

You are on an ancient version of Etherpad.

https://scanner.etherpad.org/

[sylwesterdigital]

I just installed it. The issue was it is behind basic Auth, now using Etherscan Auth

[JohnMcLear]

Is that a plugin issue or something then? I haven't seen that UI in years!

Can you provide steps to replicate? Turn basic auth on, hit index page, get presented with this?

[SamTV12345]

I just installed it. The issue was it is behind basic Auth, now using Etherscan Auth

You can see the problem in the screenshot. The normal ui uses collibri as a theme. This is basically the ui without any styling. Could be a suddle change in the welcome.html file which caused this issue.

[JohnMcLear]

I'll look into it, I think the STR is enable basic auth yea?

[JohnMcLear]

@sylwesterdigital can you please confirm STR? I'm looking into it but as your bug report didn't meet the template requirements its hard for me to help you.

[JohnMcLear]

Did some digging — I don't think the 400 is coming from Etherpad core.

/static/*filename is registered in expressPreSession (src/node/hooks/express/static.ts), so it's wired in before webaccess.checkAccess. Basic-auth shouldn't gate skin assets at all. To confirm, I reproduced on master (2.7.2) with requireAuthentication: true and a users block:

$ curl -i 'http://127.0.0.1:9099/static/skins/colibris/index.css?v=abcd'
HTTP/1.1 200 OK
Content-Type: text/css; charset=utf-8

Same 200 with valid creds, with no creds, with a Safari UA, and with the ?v= query string. Minify.ts only writes 200/304/404/405 — no code path in core returns 400 for static assets, and grepping core for status(400) / writeHead(400) only turns up tokenTransfer, apicalls, ImportHandler and the openapi schema (none of which can be hit by a /static/... URL).

So the 400 has to be coming from outside the route handler. @sylwesterdigital — to narrow it down, could you share:

1. Reverse proxy? Is Etherpad sitting behind nginx / Caddy / Apache / Cloudflare? You mentioned switching to "Etherscan Auth" — if that's an auth-proxy in front, it's the likeliest source of the 400 (Safari's basic-auth replay behaviour on subresources is fiddly and can trip strict proxies).
2. Server log line for the failing request. With default loglevel, the connectLogger middleware logs :status, :method :url for every request — that line will tell us whether Etherpad itself logged a 400, or whether the request never reached it.
3. Full URL + response headers from Safari's Network tab for one of the failing requests (the console summary truncates to the basename).
4. settings.json (especially trustProxy, cookie.sameSite, any x-proxy-path usage) and the list of installed plugins.

If you can paste those, I can take another pass.