Hi all, I used jitsi for more than one year, and all this time I used shared server meet.jit.si.
But yesterday I started getting errors on init jitsi
Access to XMLHttpRequest at 'https://meet.jit.si/http-bind?room=room-id-134' from origin 'https://my.domain.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains multiple values 'https://my.domain.com, *', but only one is allowed.
I can’t find what exactly changed on config after an update. Maybe someone can help me, what is changed and what I should change on my side. Thanks
Yes. Same issue here. Any help would be appreciated!
It seems for the OPTIONS response, the meet.jit.si response contains the following headers
Which the latest Chrome browser does not like it.
Can you reproduce the problem using curl ?
So, can be, but at opera wiht “89.0.4389.114” version, the same problem
No, with curl all is fine
Well, if it works with curl it’s a mystery since HTTP is supposed to be a stateless protocol - unless there are cookies set when accessing from the browser. You could possibly explore this using a sniffer such as with this article. I have checked and under Linux recent Firefox still generates the key file. Did not check if it actually works though.
Do you have Jitsi inside iframe?
Is this a response from your server or from
$ curl --header 'Origin: https://foo' --verbose https://meet.jit.si/http-bind 2>&1 | grep access-control-allow-origin
< access-control-allow-origin: https://foo
< access-control-allow-origin: *
This is a misconfiguration on the meet.jit.si server. By the CORS spec, if
* is present then nothing else should be present. @damencho FYI
No, I using lib-jitsi-meet API (low level)
I have never thought of sending such a header to a server; casual browsing of the internet always refers to this header being part of the response, where did you find the ref for this query to have a meaning ? without it, meet.jit.si returns 2 occurences of ‘*’, strange but not leading to an error message I think.
Origin is a standard HTTP header sent by all modern browsers in cross-origin requests (and in same-origin requests other than GET/HEAD). More info at MDN.
Access-Control-Allow-Origin is sent multiple times in a response, it’s the same as a single header with the values comma-separated.
*, * is not a valid value for the header, and neither is
[some origin], *. The misconfiguration is surely the cause of the error in the OP.
@jpg oops I did read a bit too fast and I mixed up Origin and Access-control-allow-origin
Oops, thanks for the heads up on this! We’ve moved to the latest prosody 0.12.0 which is now sending an additional unexpected header. I’m studying this now and hope to release a fix shortly.
We’re using the appropriate setting as per Setting up a BOSH server – Prosody IM
cross_domain_bosh = false;
I hope to have more to report soon.
My findings are that prosody 0.12.0 adds CORS headers by default now and has no option to disable them directly. 0.12.1 may include such a feature, but in the meantime we are suppressing the prosody values via additional nginx rules.
This fix has been applied to the live servers on https://meet.jit.si/ so please let us know if anybody continues to experience any issues with bad CORS headers.
proxy_hide_header work as a temporary solution?