mode: 'no-cors'
nie sprawi, że wszystko zacznie działać. W rzeczywistości pogarsza to sytuację, ponieważ jednym z efektów jest mówienie przeglądarkom: „Zablokuj mojemu kodowi JavaScript frontendu przeglądanie zawartości treści odpowiedzi i nagłówków w każdych okolicznościach”. Oczywiście, że prawie nigdy tego nie chcesz.
To, co dzieje się w przypadku żądań między źródłami z frontendowego JavaScript, polega na tym, że przeglądarki domyślnie blokują kod frontendu przed dostępem do zasobów między źródłami. Jeśli Access-Control-Allow-Origin
jest w odpowiedzi, przeglądarki złagodzą to blokowanie i pozwolą Twojemu kodowi uzyskać dostęp do odpowiedzi.
Ale jeśli witryna wysyła „nie” Access-Control-Allow-Origin
w swoich odpowiedziach, kod frontendu nie może uzyskać bezpośredniego dostępu do odpowiedzi z tej witryny. W szczególności nie można tego naprawić, określając mode: 'no-cors'
(w rzeczywistości zapewni to, że kod frontendu nie będzie miał dostępu do treści odpowiedzi).
Jednak jedna rzecz, która będzie działać: jeśli wysyłasz żądania przez pełnomocnika Cors , jak poniżej:
var proxyUrl = 'https://cors-anywhere.herokuapp.com/',
targetUrl = 'http://catfacts-api.appspot.com/api/facts?number=99'
fetch(proxyUrl + targetUrl)
.then(blob => blob.json())
.then(data => {
console.table(data);
document.querySelector("pre").innerHTML = JSON.stringify(data, null, 2);
return data;
})
.catch(e => {
console.log(e);
return e;
});
<pre></pre>
Uwaga: jeśli spróbujesz użyć https://cors-anywhere.herokuapp.com, okaże się, że jest wyłączony , możesz również łatwo wdrożyć własne proxy na Heroku w dosłownie zaledwie 2-3 minuty, za pomocą 5 poleceń:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
Po uruchomieniu tych poleceń otrzymasz własny serwer CORS Anywhere działający np . Pod adresem https://cryptic-headland-94862.herokuapp.com/ . Więc zamiast poprzedzać adres URL żądania https://cors-anywhere.herokuapp.com
przedrostkiem, należy poprzedzić go adresem URL własnej instancji; np . https://cryptic-headland-94862.herokuapp.com/https://example.com .
Mogę trafić na ten punkt końcowy http://catfacts-api.appspot.com/api/facts?number=99
przez Postman
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS wyjaśnia, dlaczego jest tak, że chociaż możesz uzyskać dostęp do odpowiedzi za pomocą programu Postman, przeglądarki nie pozwalają na dostęp do odpowiedzi z różnych źródeł z frontendu Kod JavaScript działający w aplikacji internetowej, chyba że odpowiedź zawiera Access-Control-Allow-Origin
nagłówek odpowiedzi.
http://catfacts-api.appspot.com/api/facts?number=99 nie ma Access-Control-Allow-Origin
nagłówka odpowiedzi, więc nie ma możliwości, aby kod frontendu mógł uzyskać dostęp do odpowiedzi z różnych źródeł.
Twoja przeglądarka może uzyskać odpowiedź w porządku i możesz ją zobaczyć w programie Postman, a nawet w narzędziach programistycznych przeglądarki - ale to nie znaczy, że przeglądarki udostępnią ją Twojemu kodowi. Nie zrobią tego, ponieważ nie ma Access-Control-Allow-Origin
nagłówka odpowiedzi. Więc zamiast tego musisz użyć proxy, aby go uzyskać.
Serwer proxy wysyła żądanie do tej witryny, pobiera odpowiedź, dodaje Access-Control-Allow-Origin
nagłówek odpowiedzi i wszelkie inne potrzebne nagłówki CORS, a następnie przekazuje je z powrotem do kodu żądającego. A ta odpowiedź z Access-Control-Allow-Origin
dodanym nagłówkiem jest tym, co widzi przeglądarka, więc przeglądarka pozwala kodowi frontendu faktycznie uzyskać dostęp do odpowiedzi.
Więc próbuję przekazać obiekt do mojego Fetch, który wyłączy CORS
Nie chcesz tego robić. Aby było jasne, kiedy mówisz, że chcesz „wyłączyć CORS”, wydaje się, że w rzeczywistości chcesz wyłączyć politykę tego samego pochodzenia . Sam CORS jest w rzeczywistości sposobem na to - CORS jest sposobem na poluzowanie zasad tego samego pochodzenia, a nie sposobem na ich ograniczenie.
W każdym razie to prawda, że możesz - tylko w swoim środowisku lokalnym - robić takie rzeczy, jak nadawanie flagom czasu wykonywania przeglądarki, aby wyłączyć zabezpieczenia i działać niezabezpiecznie, lub możesz zainstalować rozszerzenie przeglądarki lokalnie, aby obejść zasady tego samego pochodzenia, ale wszystko to robi to lokalna zmiana sytuacji tylko dla Ciebie.
Bez względu na to, co zmienisz lokalnie, każdy inny użytkownik, który spróbuje użyć Twojej aplikacji, nadal będzie miał do czynienia z polityką tego samego pochodzenia i nie ma możliwości wyłączenia tego dla innych użytkowników Twojej aplikacji.
Najprawdopodobniej nigdy nie chcesz używać mode: 'no-cors'
w praktyce, z wyjątkiem kilku ograniczonych przypadków , a nawet wtedy, gdy wiesz dokładnie, co robisz i jakie są efekty. Dzieje się tak, ponieważ ustawienie mode: 'no-cors'
faktycznie mówi do przeglądarki: „Zablokuj mojemu kodowi JavaScript frontendu wgląd w treść odpowiedzi i nagłówki w każdych okolicznościach”. W większości przypadków to oczywiście nie jest to, czego chcesz.
Jeśli chodzi o przypadki, w których chciałbyś rozważyć użycie mode: 'no-cors'
, zapoznaj się z odpowiedzią w artykule Jakie ograniczenia dotyczą nieprzejrzystych odpowiedzi? po szczegóły. Istota sprawy polega na tym, że przypadki są:
W przypadku ograniczonej gdy jesteś przy użyciu JavaScript, aby umieścić zawartość z innego pochodzenia do <script>
, <link rel=stylesheet>
, <img>
, <video>
, <audio>
, <object>
, <embed>
, lub <iframe>
elementu (który działa z powodu osadzania zasobów krzyżowo-origin jest dozwolona dla osób) - ale z jakiegoś powodu don” Nie chcesz lub nie możesz tego zrobić, używając tylko znaczników dokumentu jako adresu URL zasobu jako atrybutu href
lub src
dla elementu.
Gdy jedyną rzeczą, którą chcesz zrobić z zasobem, jest buforowanie go. Jak wspomniano w odpowiedzi, jakie ograniczenia dotyczą nieprzejrzystych odpowiedzi? , w praktyce scenariusz ma zastosowanie, gdy używasz Service Workers, w którym to przypadku interfejs API, który ma znaczenie, to interfejs API pamięci podręcznej .
Ale nawet w tych ograniczonych przypadkach istnieje kilka ważnych problemów, o których należy pamiętać; zobacz odpowiedź w sekcji Jakie ograniczenia dotyczą nieprzejrzystych odpowiedzi? po szczegóły.
Próbowałem też przejść do obiektu { mode: 'opaque'}
Nie ma mode: 'opaque'
trybu żądania - opaque
zamiast tego jest po prostu właściwością odpowiedzi , a przeglądarki ustawiają tę nieprzezroczystą właściwość w odpowiedziach z żądań wysyłanych za pomocą tego no-cors
trybu.
Ale nawiasem mówiąc, słowo nieprzezroczysty jest dość wyraźnym sygnałem o naturze odpowiedzi, którą otrzymujesz: „nieprzejrzysty” oznacza, że nie możesz jej zobaczyć.
cors-anywhere
obejście prostych przypadków użycia innych niż produkty (np. Pobieranie niektórych publicznie dostępnych danych). Ta odpowiedź potwierdza moje podejrzenie, któreno-cors
nie jest powszechne, ponieważ jej OpaqueResponse nie jest zbyt przydatna; tj. „bardzo ograniczone przypadki”; Czy ktoś może mi wyjaśnić przykłady, gdzieno-cors
jest przydatne?