Dashboard 2 behind authenticating reverse proxy

[Fredrik]

@kitori It looks like Dashboard sets Access-Control-Allow-Origin to '*' which according to Google SHOULD mean everywhere, but for some reason isn't. Anybody have any idea why, does this header need to be explicit in certain cases or something like that?

Anyway, I think you might be on to something. I've configured Traefik to overwrite the header with my explicit URL. Now let's wait and see...

[TotallyInformation]

@Fredrik

Anybody have any idea why

The only thing I can think of immediately is that maybe browsers or the proxy are ignoring it since I don't believe it is considered good practice? It rather negates the reasons for using CORS in the first place doesn't it?

[TotallyInformation]

Actually, I thought of another possibility.

Maybe you are hitting something I came across recently as well? That Socket.IO has its own header handling. Perhaps it is Socket.IO connections that have problems?

[kitori]

more tinkering:

i have 2 domains: auth.xyz.com and board.xyz.com

auth -> authelia
board -> node-red

if i am not logged in in auth, auth is requested from board --> which is not allowed

so i added this snippet to auth

nginx enabling CORS for multiple subdomains

In your case, the Domain login.microsoft ist called from noderd.furtenbach.org -- which is not allowed.

[Colin]

I think probably the immediate cause is not important. The solution is to catch all failure modes on connection and force a full page reload, there are one or two situations where this does not happen. I can probably implement that but not for a couple of weeks due to pressure of other stuff.

[hardillb]

The only thing I can see is we set is this

"Content-Security-Policy", "frame-ancestors 'self' ${settings.forgeURL}"

But that's for the embedded editor iirc