CORS issue?
Hi,
Thanks so much for sniproxy, it is a great tool, love it!
However, I am struggling to make it work for CanalPlus, here is an example of what I have while I am connected to a VPN in France:
$ curl 'https://dsh-m013.p-cdnlive-edge010102.scy.canalplus-cdn.net/ora01-28dd38a690f1e52cd78f26dccfc93541-a370/live/disk/m6-hd/_shared_a3abfd0f9419a17cb1dc423c9d593bf7/m6-hd-mp4a_96000_fra=20000-2404423611352444.mp4' \
-H 'authority: dsh-m013.p-cdnlive-edge010102.scy.canalplus-cdn.net' \
-H 'accept: */*' \
-H 'accept-language: en-US,en;q=0.9' \
-H 'origin: https://www.canalplus.com' \
-H 'referer: https://www.canalplus.com/' \
-H 'sec-ch-ua: "Chromium";v="104", " Not A;Brand";v="99", "Google Chrome";v="104"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'sec-ch-ua-platform: "macOS"' \
-H 'sec-fetch-dest: empty' \
-H 'sec-fetch-mode: cors' \
-H 'sec-fetch-site: cross-site' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36' \
--compressed
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
Everything works perfectly. However, when I am using my sniproxy instance, it says this:
$ curl 'https://dsh-m013.p-cdnlive-edge010102.scy.canalplus-cdn.net/ora01-28dd38a690f1e52cd78f26dccfc93541-a370/live/disk/m6-hd/_shared_a3abfd0f9419a17cb1dc423c9d593bf7/m6-hd-mp4a_96000_fra=20000-2404423611352444.mp4' \
-H 'authority: dsh-m013.p-cdnlive-edge010102.scy.canalplus-cdn.net' \
-H 'accept: */*' \
-H 'accept-language: en-US,en;q=0.9' \
-H 'origin: https://www.canalplus.com' \
-H 'referer: https://www.canalplus.com/' \
-H 'sec-ch-ua: "Chromium";v="104", " Not A;Brand";v="99", "Google Chrome";v="104"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'sec-ch-ua-platform: "macOS"' \
-H 'sec-fetch-dest: empty' \
-H 'sec-fetch-mode: cors' \
-H 'sec-fetch-site: cross-site' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36' \
--compressed
Access denied [C]
I made sure that the domain resolved in my VPS IP when I do
$ nslookup dsh-m013.p-cdnlive-edge010102.scy.canalplus-cdn.net VPS_IP
Server: VPS_IP
Address: VPS_IP#53
Non-authoritative answer:
Name: dsh-m013.p-cdnlive-edge010102.scy.canalplus-cdn.net
Address: VPS_IP
Could it be from CORS? Any pointers on how to solve this?
Thanks so much in advance!
I faced the same issue, but while trying to proxify Facebook – it shows me "CORS Missing Allow Origin". To what I found, it happens due to "302 Found" to "Location: /", obviously without CORS-headers in the response.
Are your requests to the service sent thru sniproxy? Probably CDN's URL which was returned by API service has some kind of IP pinning and CDN expecting the request only from some certain host, denying all others.
However in my case all API and CDN domains are mapped to VPS and all requests are passing thru sniproxy, but it still fails. I've:
- tcpdumped the traffic passing from sniproxy to Facebook, in case if SNI is cut at that point, but it's all fine.
- dropped ipv6 records in the mapping
- copied whole URL of sucha failed query and all the headers (UA, Referer, Sec-***) to curl and executed it — I've got 200 and correct content. doh
Can't imagine where and how to check further.
"CORS Missing Allow Origin" I faced the same issue but there is no issue when I tried to used controld.com as Smart DNS. So I think there is something here to make it works
@scopolamine1401 where do you get the message "CORS Missing Allow Origin"? Could you please share logs?
6 days ago
It is in Network tab of Inspect of Chrome. Check the response
Did some experiments. Now I believe it happens due to HTTP/2 – disabling HTTP/2 in my Firefox helped me with Facebook. Could you guys check this for your cases?
Found the issue here – https://github.com/dlundquist/sniproxy/issues/178, but have no time at the moment to study it.
Doh. Better comment on the problem is here:
https://github.com/dlundquist/sniproxy/issues/329#issuecomment-473511721 The HTTP/2 multiplexing is to blame. Google uses HTTP/2 to enhance their performance. If there are many resources to be requested which is hosted on single IP, the browser will combine these requests into one connection, which may led SNIProxy to forward the connection to an incorrect server.