The 'Access-Control-Allow-Origin' header contains multiple values

users meet.jit.si
#1

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 :slight_smile:

1 Like
CORS policy error: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains multiple values i.e domain name , *, but only one is allowed
#2

Yes. Same issue here. Any help would be appreciated! :upside_down_face:

It seems for the OPTIONS response, the meet.jit.si response contains the following headers

    access-control-allow-origin: https://my.domain.com
    access-control-allow-origin:  *

Which the latest Chrome browser does not like it.

#3

Can you reproduce the problem using curl ?

#5

So, can be, but at opera wiht “89.0.4389.114” version, the same problem

#6

No, with curl all is fine

#7

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.

#8

Do you have Jitsi inside iframe?
Is this a response from your server or from meet.jit.si?

#9 
$ 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

4 Likes
#10

No, I using lib-jitsi-meet API (low level)

#11

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.

#12

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.

When 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.

#13

@jpg oops I did read a bit too fast and I mixed up Origin and Access-control-allow-origin :frowning:

1 Like
#14

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.

6 Likes
#15

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.

6 Likes
#16

So does proxy_hide_header work as a temporary solution?

proxy_hide_header Access-Control-Allow-Origin;
2 Likes
#17

Yes.