Najwyraźniej zupełnie nie zrozumiałem jego semantyki. Myślałem o czymś takim:

1. Klient pobiera kod javascript MyCode.js z http://siteA- źródła .
2. Nagłówek odpowiedzi MyCode.js zawiera Access-Control-Allow-Origin:http://siteB co, jak sądzę, oznacza, że ​​MyCode.js może tworzyć odniesienia do witryny B.
3. Klient uruchamia niektóre funkcje MyCode.js, które z kolei wysyłają żądania do http://siteB, co powinno być w porządku, mimo że są żądaniami pochodzącymi z różnych źródeł.

Cóż, mylę się. To wcale tak nie działa. Przeczytałem Udostępnianie zasobów pochodzących z różnych źródeł i próbowałem przeczytać Udostępnianie zasobów pochodzących z różnych źródeł w zaleceniu w3c

Jedno jest pewne - nadal nie rozumiem, jak mam korzystać z tego nagłówka.

Mam pełną kontrolę zarówno nad witryną A, jak i witryną B. Jak włączyć kod javascript pobrany z witryny A, aby uzyskać dostęp do zasobów w witrynie B za pomocą tego nagłówka?

PS

Nie chcę korzystać z JSONP.

Access-Control-Allow-Originto nagłówek CORS (Cross-Origin Resource Sharing) .

Gdy witryna A próbuje pobrać treść z witryny B, witryna B może wysłać Access-Control-Allow-Originnagłówek odpowiedzi, aby poinformować przeglądarkę, że zawartość tej strony jest dostępna dla niektórych źródeł. ( Pochodzenie to domena oraz schemat i numer portu ). Domyślnie strony witryny B nie są dostępne dla żadnego innego źródła ; użycie Access-Control-Allow-Originnagłówka otwiera drzwi do dostępu między źródłami według określonych żądań pochodzenia.

Dla każdego zasobu / strony, którą Witryna B chce udostępnić dla Witryny A, Witryna B powinna wyświetlać swoje strony z nagłówkiem odpowiedzi:

Access-Control-Allow-Origin: http://siteA.com

Nowoczesne przeglądarki nie będą blokować żądań między domenami. Jeśli witryna A zażąda strony z witryny B, przeglądarka faktycznie pobierze żądaną stronę na poziomie sieci i sprawdzi, czy nagłówki odpowiedzi wskazują witrynę A jako dozwoloną domenę żądającego. Jeśli strony B nie wskazał, że strony A jest dostęp do tej strony, przeglądarka wywoła XMLHttpRequest„s errorzdarzenie i zaprzeczyć danych odpowiedzi do żądającego kodu JavaScript.

Nie proste prośby

To, co dzieje się na poziomie sieci, może być nieco bardziej skomplikowane niż wyjaśniono powyżej. Jeśli żądanie to „niełatwym” , przeglądarka najpierw wysyła żądanie OPCJI „bez kontroli danych”, aby sprawdzić, czy serwer zaakceptuje żądanie. Żądanie nie jest proste, gdy (lub oba):

• za pomocą czasownika HTTP innego niż GET lub POST (np. PUT, DELETE)
• używanie nieprostych nagłówków żądań; jedyne proste nagłówki żądań to:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(jest to tylko prosta, gdy jego wartość jest application/x-www-form-urlencoded, multipart/form-datalub text/plain)

Jeśli serwer odpowie na inspekcję wstępną OPCJE za pomocą odpowiednich nagłówków odpowiedzi (w Access-Control-Allow-Headersprzypadku nieprostych nagłówków, Access-Control-Allow-Methodsw przypadku czasowników niebędących prostymi), które pasują do nie-prostych czasowników i / lub nie-prostych nagłówków, przeglądarka wysyła rzeczywiste żądanie.

Przypuśćmy, że strona A chce wysłać żądanie podniesiony /somePage, z non-proste Content-Typewartości application/json, przeglądarka musi najpierw wysłać żądanie inspekcji wstępnej:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Pamiętaj, że Access-Control-Request-Methodi Access-Control-Request-Headerssą automatycznie dodawane przez przeglądarkę; nie musisz ich dodawać. Ta inspekcja wstępna OPCJE uzyskuje nagłówki udanej odpowiedzi:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

Podczas wysyłania rzeczywistego żądania (po zakończeniu inspekcji wstępnej) zachowanie jest identyczne jak w przypadku obsługi prostego żądania. Innymi słowy, niełatwe żądanie, którego inspekcja wstępna zakończy się powodzeniem, jest traktowane tak samo jak proste żądanie (tzn. Serwer musi nadal wysłać Access-Control-Allow-Originponownie w celu uzyskania rzeczywistej odpowiedzi).

Przeglądarki wysyłają aktualne żądanie:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

A serwer odsyła Access-Control-Allow-Origin, tak jak w przypadku prostego żądania:

Access-Control-Allow-Origin: http://siteA.com

Zobacz Zrozumienie XMLHttpRequest nad CORS, aby uzyskać więcej informacji na temat nieprostych żądań.

Udostępnianie zasobów między różnymi źródłami - CORS(żądanie AJAX między domenami AKA) to problem, z którym większość programistów internetowych może się spotkać, zgodnie z zasadami tego samego pochodzenia, przeglądarki ograniczają JavaScript klienta w bezpiecznym obszarze izolowanym, zwykle JS nie może bezpośrednio komunikować się ze zdalnym serwerem z innej domeny. W przeszłości programiści tworzyli wiele trudnych sposobów realizacji żądania zasobów między domenami, najczęściej za pomocą następujących sposobów:

1. Użyj Flash / Silverlight lub strony serwera jako „proxy” do komunikacji ze zdalnym.
2. JSON With Padding ( JSONP ).
3. Osadza zdalny serwer w ramce iframe i komunikuje się przez fragment lub window.name, patrz tutaj .

Te trudne sposoby mają mniej lub bardziej pewne problemy, na przykład JSONP może spowodować lukę w zabezpieczeniach, jeśli programiści po prostu go „ewaluują”, a powyżej 3, chociaż działa, obie domeny powinny zbudować między sobą ścisłą umowę, nie jest ani elastyczny, ani elegancki MOIM ZDANIEM:)

Firma W3C wprowadziła wspólne udostępnianie zasobów (CORS) jako standardowe rozwiązanie zapewniające bezpieczny, elastyczny i zalecany standardowy sposób rozwiązania tego problemu.

Mechanizm

Z wysokiego poziomu możemy po prostu uznać, że CORS jest umową między wywołaniem klienta AJAX z domeny A a stroną hostowaną w domenie B, typowe żądanie / odpowiedź między źródłami to:

Domeny AJAX nagłówki żądań

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

Nagłówki odpowiedzi DomainB

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

Niebieskie części, które zaznaczyłem powyżej, to fakty kernalne: „Nagłówek żądania pochodzenia” wskazuje, skąd pochodzi żądanie krzyżowania pochodzenia lub żądania kontroli wstępnej ”, nagłówek odpowiedzi„ Kontrola dostępu - zezwól na pochodzenie ”wskazuje, że ta strona zezwala na zdalne żądanie z Domena A (jeśli wartość * wskazuje, zezwala na zdalne żądania z dowolnej domeny).

Jak wspomniałem powyżej, W3 zaleca przeglądarce, aby wdrożyła „ żądanie inspekcji wstępnej ” przed przesłaniem faktycznie żądania HTTP Cross-Origin, w skrócie jest to OPTIONSżądanie HTTP :

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Jeśli foo.aspx obsługuje OPCJE czasownik HTTP, może zwrócić odpowiedź jak poniżej:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

Tylko jeśli odpowiedź zawiera „Kontrola dostępu - Zezwalaj na pochodzenie” ORAZ jej wartość to „*” lub zawiera domenę, która przesłała żądanie CORS, spełniając ten warunek mandatu, przeglądarka prześle rzeczywiste żądanie między domenami i buforuje wynik w „ Pamięć podręczna wyników inspekcji wstępnej ”.

Napisałem o CORS trzy lata temu: żądanie HTTP AJAX Cross-Origin

Pytanie jest trochę za stare, aby odpowiedzieć, ale zamieszczam je w celu odniesienia do tego pytania w przyszłości.

Zgodnie z tym artykułem Mozilla Developer Network:

Zasób wysyła żądanie HTTP z innego źródła, gdy żąda zasobu z innej domeny lub portu niż ten, który obsługuje sam pierwszy zasób.

Strona HTML podawane http://domain-a.comsprawia <img>wniosek src dla http://domain-b.com/image.jpg.
Wiele stron w Internecie ładuje dziś zasoby, takie jak arkusze stylów CSS , obrazy i skrypty z oddzielnych domen (dlatego powinno być fajnie).

Polityka tego samego pochodzenia

Ze względów bezpieczeństwa przeglądarki ograniczają żądania HTTP pochodzące z różnych źródeł inicjowane z poziomu skryptów .
Na przykład XMLHttpRequesti Fetchprzestrzegaj zasad tego samego pochodzenia .
Tak więc aplikacja internetowa korzystająca z żądań HTTPXMLHttpRequest lub Fetchtylko do własnej domeny .

Udostępnianie zasobów między źródłami (CORS)

Aby ulepszyć aplikacje internetowe, programiści poprosili dostawców przeglądarek o zezwolenie na żądania między domenami.

Mechanizm współdzielenia zasobów między źródłami (CORS) zapewnia serwerom internetowym kontrolę dostępu między domenami , które umożliwiają bezpieczny transfer danych między domenami.
Nowoczesne przeglądarki używają CORS w kontenerze API - takim jak XMLHttpRequestlub Fetch- w celu zmniejszenia ryzyka żądań HTTP pochodzących z różnych źródeł.

Jak działa CORS ( Access-Control-Allow-Originnagłówek)

Wikipedia :

Standard CORS opisuje nowe nagłówki HTTP, które umożliwiają przeglądarkom i serwerom żądanie zdalnego adresu URL tylko wtedy, gdy mają na to pozwolenie.

Chociaż serwer może przeprowadzić pewną weryfikację i autoryzację, przeglądarka jest odpowiedzialna za obsługę tych nagłówków i przestrzeganie nakładanych przez nie ograniczeń.

Przykład

1. Przeglądarka wysyła OPTIONSżądanie zOrigin HTTP nagłówkiem.

   Wartością tego nagłówka jest domena obsługująca stronę nadrzędną. Gdy strona z http://www.example.compróby uzyskania dostępu do danych użytkownika, service.example.comzostanie wysłany następujący nagłówek żądania service.example.com:

   Pochodzenie: http://www.example.com

2. Serwer at service.example.commoże odpowiedzieć:

   • Access-Control-Allow-Origin(ACAO) Nagłówek w odpowiedzi wskazuje, które miejsca pochodzenia są dozwolone.
     Na przykład:

     Access-Control-Allow-Origin: http://www.example.com

   • Strona błędu, jeśli serwer nie zezwala na żądanie krzyżowego pochodzenia

   • Access-Control-Allow-Origin(ACAO) header asterisk który pozwala wszystkich domen:

     Access-Control-Allow-Origin: *

Ilekroć zaczynam myśleć o CORS, moja intuicja dotycząca tego, która witryna zawiera nagłówki, jest nieprawidłowa, tak jak opisano w pytaniu. Dla mnie pomaga zastanowić się nad celem tej samej polityki pochodzenia.

Celem tej samej zasady pochodzenia jest ochrona przed złośliwym skryptem JavaScript w witrynie siteA.com uzyskującym dostęp do prywatnych informacji, które zostały udostępnione tylko w witrynie siteB.com. Bez tej samej zasady pochodzenia JavaScript napisany przez autorów siteA.com może powodować, że Twoja przeglądarka wysyła żądania do siteB.com, wykorzystując twoje uwierzytelniające pliki cookie dla siteB.com. W ten sposób siteA.com może ukraść tajne informacje, które udostępniasz witrynie siteB.com.

Czasami musisz pracować w wielu domenach, do których wkracza CORS. CORS rozluźnia tę samą zasadę pochodzenia dla domainB.com, używając Access-Control-Allow-Origin nagłówka, aby wyświetlić listę innych domen (domainA.com), którym powierzono zaufanie do uruchamiania JavaScript, który może wchodzić w interakcje z domeną A. com.

Aby zrozumieć, która domena powinna obsługiwać nagłówki CORS, rozważ to. Odwiedzasz szkodliwe.com, które zawiera JavaScript, który próbuje wysłać żądanie do domeny z mybank.com. Decyzja o tym, czy ustawia nagłówki CORS, które rozluźniają tę samą zasadę pochodzenia, pozwala JavaScript z złośliwą witryną. Jeśli malicous.com może ustawić własne nagłówki CORS zezwalające na własny dostęp JavaScript do mybank.com, całkowicie unieważniłoby to tę samą zasadę pochodzenia.

Myślę, że powodem mojej złej intuicji jest punkt widzenia, który mam przy tworzeniu witryny. To moja strona z całym moim JavaScript, dlatego nie robi nic złośliwego i ode mnie powinno zależeć, z którymi innymi stronami mój JavaScript może wchodzić w interakcje. Kiedy w rzeczywistości powinienem zastanowić się, które inne witryny JavaScript próbują wchodzić w interakcje z moją witryną i czy powinienem używać CORS, aby im na to pozwolić?

1. Klient pobiera kod javascript MyCode.js z http: // siteA - pochodzenie.

Kod, który wykonuje pobieranie - twój tag skryptu HTML lub xhr z javascript lub cokolwiek innego - pochodzi, powiedzmy, z http: // siteZ . A gdy przeglądarka żąda MyCode.js, wysyła nagłówek Origin: „Origin: http: // siteZ ”, ponieważ może zobaczyć, że prosisz o siteA i siteZ! = SiteA. (Nie możesz przestać lub wtrącać się w to.)

2. Nagłówek odpowiedzi MyCode.js zawiera Access-Control-Allow-Origin: http: // siteB , co, jak sądzę, oznacza, że ​​MyCode.js może tworzyć odniesienia do witryn B.

Nie. Oznacza to, że tylko witryna B może wykonać to żądanie. Więc twoje żądanie MyCode.js z siteZ otrzymuje błąd, a przeglądarka zazwyczaj nie daje ci nic. Ale jeśli sprawisz, że serwer zwróci ACAO: siteZ, otrzymasz MyCode.js. Lub jeśli wyśle ​​„*”, to zadziała, to wpuści wszystkich. Lub jeśli serwer zawsze wysyła ciąg z nagłówka Origin: ... ale ... dla bezpieczeństwa, jeśli boisz się hakerów , Twój serwer powinien zezwalać tylko na źródła z krótkiej listy, które mogą wysyłać te żądania.

Następnie MyCode.js pochodzi z witryny A. Gdy wysyła żądania do witryny B, wszystkie pochodzą z innego źródła, przeglądarka wysyła Źródło: witryna A, a witryna B musi przejąć witrynę A, rozpoznać ją na krótkiej liście dozwolonych żądających i odesłać ACAO: witryna A. Tylko wtedy przeglądarka pozwoli skryptowi uzyskać wynik tych żądań.

Używając React i Axios , dołącz link proxy do adresu URL i dodaj nagłówek, jak pokazano poniżej

https://cors-anywhere.herokuapp.com/ + Your API URL

Tylko dodanie linku proxy będzie działało, ale może również ponownie wygenerować błąd dla braku dostępu. Dlatego lepiej dodać nagłówek, jak pokazano poniżej.

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

Jeśli chcesz tylko przetestować aplikację między domenami, w której przeglądarka blokuje twoje żądanie, możesz po prostu otworzyć przeglądarkę w trybie niebezpiecznym i przetestować aplikację bez zmiany kodu i bez uczynienia kodu bezpiecznym. W systemie MAC OS możesz to zrobić z linii terminala:

open -a Google\ Chrome --args --disable-web-security --user-data-dir

Jeśli używasz PHP, spróbuj dodać następujący kod na początku pliku php:

Jeśli używasz localhost, spróbuj tego:

header("Access-Control-Allow-Origin: *");

Jeśli używasz domen zewnętrznych, takich jak serwer, spróbuj tego:

header("Access-Control-Allow-Origin: http://www.website.com");

pracuję z express 4 i węzłem 7.4 i kątowym, miałem ten sam problem, pomogę to:
a) po stronie serwera: w pliku app.js podaję nagłówki do wszystkich odpowiedzi, takich jak:

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

to musi mieć przed wszystkimi routerami .
Widziałem wiele dodanych tych nagłówków:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

ale nie potrzebuję tego,
b) po stronie klienta: w send ajax musisz dodać: „withCredentials: true”, jak:

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

powodzenia.

W celu współdzielenia źródła pochodzenia ustaw nagłówek: 'Access-Control-Allow-Origin':'*';

Php: header('Access-Control-Allow-Origin':'*');

Węzeł: app.use('Access-Control-Allow-Origin':'*');

Umożliwi to udostępnianie treści dla różnych domen.

W Pythonie korzystam z Flask-CORSbiblioteki z dużym powodzeniem. Dzięki temu radzenie sobie z CORS jest bardzo łatwe i bezbolesne. Dodałem trochę kodu z poniższej dokumentacji biblioteki.

Instalowanie:

$ pip install -U flask-cors

Prosty przykład, który pozwala CORS dla wszystkich domen na wszystkich trasach:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

Bardziej szczegółowe przykłady znajdują się w dokumentacji. Użyłem prostego powyższego przykładu, aby obejść problem CORS w aplikacji jonowej, którą buduję, która musi uzyskać dostęp do oddzielnego serwera flask.

Z własnego doświadczenia trudno jest znaleźć proste wyjaśnienie, dlaczego CORS jest w ogóle problemem.

Gdy zrozumiesz, dlaczego tam jest, nagłówki i dyskusja stają się o wiele wyraźniejsze. Dam temu szansę w kilku liniach.

Chodzi o pliki cookie. Pliki cookie są przechowywane na kliencie według jego domeny.

Przykładowa historia: na twoim komputerze jest plik cookie dla yourbank.com. Może twoja sesja już tam jest.

Kluczowy punkt: kiedy klient wysyła żądanie do serwera, wyśle ​​pliki cookie przechowywane w domenie, w której znajduje się klient.

Jesteś zalogowany w przeglądarce do yourbank.com. Żądasz zobaczyć wszystkie swoje konta. yourbank.comotrzymuje stos ciasteczek i odsyła odpowiedź (twoje konta).

Jeśli inny klient wysyła do serwera żądanie pochodzenia krzyżowego , te pliki cookie są wysyłane, tak jak poprzednio. Ruh roh.

Przeglądaj do malicious.com. Złośliwy wysyła wiele próśb do różnych banków, w tym yourbank.com.

Ponieważ pliki cookie są sprawdzane zgodnie z oczekiwaniami, serwer autoryzuje odpowiedź.

Te pliki cookie są gromadzone i wysyłane razem - i teraz malicious.comma odpowiedź od yourbank.

Yikes.

Tak więc teraz pojawia się kilka pytań i odpowiedzi:

• „Dlaczego po prostu nie zablokujemy przeglądarki?” Tak. CORS.
• „Jak sobie z tym poradzić?” Niech serwer poinformuje żądanie, że CORS jest OK.

Po prostu wklej następujący kod do pliku web.config.

Zauważ, że musisz wkleić następujący kod pod <system.webServer>tagiem

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  

Nagłówek odpowiedzi Access-Control-Allow-Origin wskazuje, czy odpowiedź może być współdzielona z żądaniem kodu z danego źródła.

Header type Response       header
Forbidden header name      no

Odpowiedź, która mówi przeglądarce, aby zezwoliła kodowi z dowolnego źródła na dostęp do zasobu, będzie obejmować:

Access-Control-Allow-Origin: *

Aby uzyskać więcej informacji, odwiedź tutaj ....

Nginx i Appache

Jako dodatek do odpowiedzi apsillerów chciałbym dodać wykres wiki, który pokazuje, czy prośba jest prosta, czy nie (a OPCJE jest wysyłane przed lotem, czy nie)

W przypadku prostego żądania (np. Obrazy z łączami na gorąco ) nie musisz zmieniać plików konfiguracyjnych serwera, ale możesz dodawać nagłówki w aplikacji (hostowanej na serwerze, np. W php), jak wspomniał Melvin Guerrero w swojej odpowiedzi - ale pamiętaj : jeśli dodasz pełny cors nagłówki na twoim serwerze (config) i jednocześnie zezwalasz na proste corsy w aplikacji (np. php), to w ogóle nie zadziała.

A oto konfiguracje dwóch popularnych serwerów

• włącz CORS na Nginx ( nginx.confplik)

  Pokaż fragment kodu

  location ~ ^/index\.php(/|$) {
     ...
      add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
      add_header 'Access-Control-Allow-Credentials' 'true' always;
      if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
          add_header 'Access-Control-Allow-Credentials' 'true';
          add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
          add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
          add_header 'Content-Length' 0;
          add_header 'Content-Type' 'text/plain charset=UTF-8';
          return 204;
      }
  }

  Uruchom fragment koduUkryj wyniki

  Rozwiń fragment kodu

• włącz CORS na Appache ( .htaccessplik)

  Pokaż fragment kodu

  # ------------------------------------------------------------------------------
  # | Cross-domain Ajax requests                                                 |
  # ------------------------------------------------------------------------------
  
  # Enable cross-origin Ajax requests.
  # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
  # http://enable-cors.org/
  
  # change * (allow any domain) below to your domain
  Header set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
  Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
  Header always set Access-Control-Allow-Credentials "true"

  Uruchom fragment koduUkryj wyniki

  Rozwiń fragment kodu