Görünüşe göre, anlambilimini tamamen yanlış anladım. Böyle bir şey düşündüm:

1. A istemci indirmeleri javascript kodu MyCode.js http://siteA- kökenli .
2. MyCode.js yanıt başlığı Access-Control-Allow-Origin: içerirhttp://siteB , ki bu da MyCode.js'nin B sitesine çapraz kaynak başvurusu yapmasına izin verildiğini düşündüm.
3. İstemci, MyCode.js'nin bazı işlevlerini tetikler, bu http://siteBda çapraz kökenli istekler olmasına rağmen, iyi olması gereken istekler yapar.

Ben yanılıyorum. Hiç böyle çalışmıyor. Bu nedenle, Kaynaklar arası kaynak paylaşımını okudum ve w3c önerisinde Kaynaklar Arası Kaynak Paylaşımı'nı okumaya çalıştım

Bir şey kesin - hala bu başlığı nasıl kullanmam gerektiğini anlamıyorum.

Hem site A hem de site B üzerinde tam denetime sahibim. A başlığından indirilen javascript kodunu bu üstbilgiyi kullanarak B sitesindeki kaynaklara erişmek için nasıl etkinleştirebilirim?

PS

JSONP kullanmak istemiyorum.

Access-Control-Allow-Originbir CORS (Kaynaklar Arası Kaynak Paylaşımı) üst bilgisidir .

Site A, Site B'den içerik almaya çalıştığında, Site B Access-Control-Allow-Origintarayıcıya bu sayfanın içeriğinin belirli kökenlerden erişilebilir olduğunu bildirmek için bir yanıt başlığı gönderebilir . ( Başlangıç noktası bir etki alanı, ayrıca bir düzen ve bağlantı noktası numarasıdır .) Varsayılan olarak, Site B'nin sayfalarına başka bir kaynak tarafından erişilemez ; Access-Control-Allow-Originüstbilgiyi kullanmak, belirli istekte bulunan kökenlerle çapraz menşe erişimi için bir kapı açar.

Site B'nin Site A tarafından erişilebilir olmasını istediği her kaynak / sayfa için, Site B sayfalarına yanıt üstbilgisiyle hizmet vermelidir:

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

Modern tarayıcılar, etki alanları arası istekleri açıkça engellemez. Site A, Site B'den bir sayfa isterse, tarayıcı gerçekten istenen sayfayı ağ düzeyinde alır ve yanıt başlıklarının Site A'yı izin verilen bir istek alanı olarak listelediğini kontrol eder. B Sitesi Sitesi A Bu sayfaya erişmek için izin verildiğini belirtti değil, tarayıcı tetikleyecektir XMLHttpRequest'ın errorolayı ve istekte JavaScript koduna yanıt verilerini inkar.

Basit olmayan istekler

Ağ düzeyinde olanlar yukarıda açıklandığından biraz daha karmaşık olabilir . İstek "basit olmayan" bir istekse , tarayıcı, sunucunun isteği kabul edeceğini doğrulamak için önce veri içermeyen "ön kontrol" SEÇENEKLERİ isteği gönderir. Bir istek (veya her ikisi) aşağıdaki durumlarda basit değildir:

• GET veya POST dışında bir HTTP fiili kullanma (örn. PUT, DELETE)
• basit olmayan istek başlıklarını kullanma; sadece basit istek başlıkları şunlardır:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(bu değeri olduğunda, sadece basit application/x-www-form-urlencoded, multipart/form-dataya da text/plain)

Sunucu OPTIONS ön kontrolüne, basit olmayan fiil ve / veya basit olmayan başlıklarla eşleşen uygun yanıt üstbilgileriyle ( Access-Control-Allow-Headersbasit olmayan başlıklar için, basit Access-Control-Allow-Methodsolmayan fiiller için) yanıt verirse, tarayıcı gerçek isteği gönderir.

Site A'nın /somePage, basit olmayan bir Content-Typedeğeriyle application/json, tarayıcı için bir ön kontrol isteği göndermek istediğini varsayarsak :

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

Access-Control-Request-MethodVe Access-Control-Request-Headerstarayıcı tarafından otomatik olarak eklendiğini unutmayın ; bunları eklemenize gerek yoktur. Bu OPTIONS ön kontrol başarılı yanıt başlıklarını alır:

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

Gerçek istek gönderilirken (ön kontrol yapıldıktan sonra), davranış basit bir isteğin nasıl işlendiğiyle aynıdır. Başka bir deyişle, ön kontrolü başarılı olan basit olmayan bir istek, basit bir istekle aynı şekilde ele alınır (yani, sunucunun Access-Control-Allow-Origingerçek yanıt için yine de göndermesi gerekir ).

Tarayıcılar asıl isteği gönderir:

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

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

Ve sunucu Access-Control-Allow-Originbasit bir istekte olduğu gibi bir geri gönderir :

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

Basit olmayan istekler hakkında biraz daha fazla bilgi için CORS üzerinden XMLHttpRequest'i Anlama konusuna bakın .

Kaynaklar Arası Kaynak Paylaşımı - CORS(AKA Etki Alanları Arası AJAX isteği), çoğu Web geliştiricisinin Aynı Kaynaklı Politika'ya göre karşılaşabileceği bir sorundur, tarayıcılar güvenlik sanal alanındaki istemci JavaScript'i kısıtlar, genellikle JS uzak bir sunucuyla doğrudan iletişim kuramaz farklı bir alandan. Geçmişte geliştiriciler, Etki Alanları Arası kaynak isteğini gerçekleştirmek için birçok zor yol oluşturdular, en yaygın kullanılan yöntemler şunlardır:

1. Uzaktan kumanda ile iletişim kurmak için "proxy" olarak Flash / Silverlight veya sunucu tarafını kullanın.
2. Dolgu ile JSON ( JSONP ).
3. Uzak sunucuyu iframe'e gömer ve fragment veya window.name ile iletişim kurar, buraya bakın .

Bu zor yolların az ya da çok bazı sorunları vardır, örneğin JSONP, geliştiriciler basitçe "değerlendirirse" ve yukarıdaki # 3, güvenlik deliği ile sonuçlanabilir, ancak her iki etki alanı da birbirleri arasında sıkı bir sözleşme yapmalıdır, ne esnek ne de zarif BENİM NACİZANE FİKRİME GÖRE:)

W3C, bu sorunu çözmek için güvenli, esnek ve önerilen standart bir yol sağlamak için Standartlar Arası Kaynak Paylaşımı'nı (CORS) tanıttı.

Mekanizma

Yüksek seviyeden, CORS'nin A alanından istemci AJAX çağrısı ile B alan adında barındırılan bir sayfa arasında bir sözleşme olduğunu düşünebiliriz, tipik bir Çapraz Kaynak isteği / yanıtı şöyle olur:

DomainA AJAX istek üstbilgileri

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 

DomainB yanıt başlıkları

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

Yukarıda işaretlediğim mavi bölümler çekirdek gerçeklerdi, "Kökeni" istek üstbilgisi ", kökenler arası istek veya ön kontrol isteğinin nereden geldiğini belirtir," Erişim-Kontrol-İzin Ver-Kökeni "yanıt başlığı, bu sayfanın DomainA (değer * ise, herhangi bir etki alanından uzak isteklere izin verir).

Yukarıda bahsettiğim gibi W3, tarayıcıya aslında Cross-Origin HTTP isteğini göndermeden önce bir " ön kontrol isteği " uygulamasını önerdi , kısaca bir HTTP OPTIONSisteğidir:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Foo.aspx, OPTIONS HTTP fiilini destekliyorsa, aşağıdaki gibi bir yanıt verebilir:

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

Yalnızca yanıt "Erişim-Denetim-İzin Verme Kökeni" içeriyorsa ve değeri "*" ise veya CORS isteğini gönderen etki alanını içeriyorsa, bu zorunlu koşul tarayıcısını karşılayarak gerçek Etki Alanları Arası isteği gönderir ve sonucu önbelleğe alır " Ön Kontrol-Sonuç-Önbellek ".

Üç yıl önce CORS hakkında blog yazdım: AJAX Cross-Origin HTTP isteği

Soru cevaplamak için biraz eski, ama ben bu soruya daha sonra başvurmak için gönderiyorum.

Göre bu Mozilla Geliştirici Ağı makalesinde,

Bir kaynak, farklı bir etki alanından veya bağlantı noktasından, ilk kaynağın sunduğu hizmetten farklı bir kaynak istediğinde çapraz kökenli bir HTTP isteği yapar.

Adresinden sunulan bir HTML sayfasıhttp://domain-a.com için <img>src isteği yapar http://domain-b.com/image.jpg.
Bugün web'deki birçok sayfa, ayrı alan adlarından CSS stil sayfaları , resimler ve komut dosyaları gibi kaynaklar yükler (bu nedenle havalı olmalıdır).

Aynı Menşe Politikası

Güvenlik nedeniyle, tarayıcılar komut dosyalarından başlatılan çapraz kökenli HTTP isteklerini kısıtlar . Örneğin, ve izleyin aynı kaynak politikası . Bu nedenle, veya kullanan bir web uygulaması yalnızca kendi etki alanına HTTP isteklerinde bulunabilir .
XMLHttpRequestFetch
XMLHttpRequestFetch

Kaynaklar Arası Kaynak Paylaşımı (CORS)

Web uygulamalarını iyileştirmek için geliştiriciler tarayıcı satıcılarından web alanları arası isteklere izin vermelerini istedi.

Çapraz Kökenli Kaynak Paylaşımı (CORS) mekanizması, web sunuculara verir alanlar arası erişim denetimlerini güvenli alanlar arası veri transferi sağlayan,.
Modern tarayıcılar , çapraz kökenli HTTP isteklerinin risklerini azaltmak için bir API kapsayıcısında ( veya gibi) CORS kullanır .XMLHttpRequestFetch

CORS nasıl çalışır ( Access-Control-Allow-Originbaşlık)

Vikipedi :

CORS standardı, tarayıcılara ve sunuculara yalnızca izinleri olduğunda uzak URL istemek için bir yol sağlayan yeni HTTP üstbilgilerini açıklar.

Sunucu tarafından bazı doğrulama ve yetkilendirme yapılabilse de , genellikle bu başlıkları desteklemek ve getirdikleri kısıtlamalara uymak tarayıcının sorumluluğundadır .

Misal

1. Tarayıcı OPTIONSisteği bir Origin HTTPbaşlık ile gönderir .

   Bu üstbilginin değeri, üst sayfaya hizmet veren alan adıdır. Bir sayfa http://www.example.comkullanıcının verilerine erişmeye çalıştığında service.example.com, aşağıdaki istek başlığı şuraya gönderilir service.example.com:

   Menşei: http://www.example.com

2. Adresindeki sunucu service.example.comaşağıdakilere yanıt verebilir:

   • Access-Control-Allow-OriginYanıtında hangi kaynak sitelere izin verildiğini gösteren bir (ACAO) başlığı.
     Örneğin:

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

   • Sunucu çapraz kaynak isteğine izin vermiyorsa bir hata sayfası

   • Access-Control-Allow-OriginTüm alanlara izin veren joker karakterli bir (ACAO) başlığı:

     Access-Control-Allow-Origin: *

CORS hakkında ne zaman düşünmeye başlasam, başlığınızı hangi siteye ev sahipliği yaptığına dair sezgilerim, tıpkı sorunuzda tarif ettiğiniz gibi yanlıştır. Benim için aynı köken politikasının amacını düşünmek yardımcı olur.

Aynı köken politikasının amacı, sizi yalnızca siteB.com ile paylaşmayı seçtiğiniz özel bilgilere erişerek siteA.com'daki kötü amaçlı JavaScript'ten korumaktır. Aynı kaynak politikası olmadan, siteA.com yazarları tarafından yazılan JavaScript, tarayıcınızın siteB.com için kimlik doğrulama çerezlerinizi kullanarak siteB.com'a istekte bulunmasını sağlayabilir. Bu şekilde, siteA.com, siteB.com ile paylaştığınız gizli bilgileri çalabilir.

Bazen CORS'ın devreye girdiği Access-Control-Allow-Originalanlar arası çalışmanız gerekir. CORS , domainA ile etkileşime girebilecek JavaScript'i çalıştırmak için güvenilir olan diğer alanları (domainA.com) listelemek için başlığı kullanarak domainB.com için aynı başlangıç ​​politikasını rahatlatır . com.

Hangi alanın CORS başlıklarına sunulması gerektiğini anlamak için bunu göz önünde bulundurun. Mybank.com'a etki alanları arası istekte bulunmaya çalışan bazı JavaScript içeren malware.com'u ziyaret edersiniz. Malware.com'un JavaScript'inin etkileşimde bulunmasına izin veren aynı başlangıç ​​politikasını gevşeten CORS başlıklarını ayarlayıp ayarlamayacağına karar vermek, malware.com'a değil, mybank.com'a bağlı olmalıdır. Malicous.com, mybank.com'a kendi JavaScript erişimine izin veren kendi CORS başlıklarını ayarlayabilirse, bu aynı başlangıç ​​politikasını tamamen geçersiz kılar.

Kötü sezgilerimin sebebinin bir site geliştirirken sahip olduğum bakış açısı olduğunu düşünüyorum. Bu var benim bütün site, benim bu nedenle kötü niyetli hiçbir şey yapmıyor, JavaScript ve kadar olmalıdır bana başka hangi sitelerin belirtmek için benim JavaScript etkileşim kurabilir. Aslında JavaScript'in sitemle etkileşime girmeye çalıştığı diğer siteleri düşünmem gerekir ve onlara izin vermek için CORS kullanmalıyım?

1. Bir istemci, http: // siteA - kaynağından MyCode.js javascript kodunu indirir .

İndirmeyi yapan kod - Javascript'ten html komut dosyası etiketiniz veya xhr veya her neyse - http: // siteZ diyelim . Ve tarayıcı MyCode.js istediğinde, "Origin: http: // siteZ " yazan bir Origin: üstbilgisi gönderir , çünkü siteA ve siteZ! = SiteA'ya istekte bulunduğunuzu görebilir. (Bunu durduramaz veya buna müdahale edemezsiniz.)

2. MyCode.js'nin yanıt üstbilgisi, MyCode.js'nin B sitesine çapraz kaynak başvuru yapmasına izin verildiğini düşündüğüm Access-Control-Allow-Origin: http: // siteB içeriyor .

Hayır. Bu, yalnızca siteB'nin bu isteği yapmasına izin verildiği anlamına gelir. SiteZ'den MyCode.js isteğiniz bunun yerine bir hata alır ve tarayıcı genellikle size hiçbir şey vermez. Ancak sunucunuzun ACAO: siteZ yerine dönmesini sağlarsanız, MyCode.js dosyasını alırsınız. Ya da '*' gönderirse, bu işe yarar, herkesin içeri girmesine izin verir. Veya sunucu dizeyi her zaman Origin: başlığından gönderirse ... ama ... güvenlik için, bilgisayar korsanlarından korkuyorsanız , sunucunuz yalnızca bu istekleri yapmalarına izin verilen bir kısa listede bulunan kökenlere izin vermelidir.

Ardından, MyCode.js siteA'dan gelir. SiteB'ye istekte bulunduğunda, bunların hepsi çapraz kökenlidir, tarayıcı Origin: siteA ve siteB'nin siteA'yı alması, izin verilen isteklerin kısa listesinde olduğunu fark etmeli ve ACAO: siteA'yı geri göndermelidir. Ancak o zaman tarayıcı komut dosyanızın bu isteklerin sonucunu almasına izin verir.

React ve Axios'u kullanarak URL'ye proxy bağlantısını ekleyin ve aşağıda gösterildiği gibi başlık ekleyin

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

Sadece Proxy bağlantısı ekleyerek işe yarayacaktır, ancak yine Erişim Yok için tekrar hata verebilir. Bu nedenle, aşağıda gösterildiği gibi başlık eklemek daha iyidir.

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

UYARI: Üretimde kullanılmaz

Bu sadece hızlı bir çözümdür, neden yanıt alamıyorsanız ile uğraşıyorsanız, bunu kullanabilirsiniz. Ama yine de üretim için en iyi cevap bu değil.

Birkaç downvotes var ve tamamen mantıklı, uzun zaman önce uyarıyı eklemeliydim.

Tarayıcının isteğinizi engellediği bir etki alanları arası uygulamayı test etmek istiyorsanız, tarayıcınızı güvenli olmayan modda açabilir ve kodunuzu değiştirmeden ve kodunuzu güvensiz hale getirmeden uygulamanızı test edebilirsiniz. MAC OS'den bunu terminal hattından yapabilirsiniz:

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

PHP kullanıyorsanız, php dosyasının başına aşağıdaki kodu eklemeyi deneyin:

Localhost kullanıyorsanız şunu deneyin:

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

Sunucu gibi harici etki alanları kullanıyorsanız, şunu deneyin:

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

i ifade 4 ve düğüm 7.4 ve açısal ile çalışmak, ben aynı sorunu bana bu yardımcı oldu:
a) sunucu tarafı: app.js dosyada gibi tüm yanıt başlıkları vermek:

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();
 });  

bunun tüm yönlendiricilerden önce olması gerekir .
Bu başlıkları çok ekledim:

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

ama buna ihtiyacım yok,
b) istemci tarafı: göndermek ajax eklemek gerekir: "withCredentials: true," gibi:

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

iyi şanslar.

Çapraz kaynak paylaşımı için başlığı ayarlayın: 'Access-Control-Allow-Origin':'*';

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

Düğüm: app.use('Access-Control-Allow-Origin':'*');

Bu, farklı alan adları için içerik paylaşmaya izin verir.

Python'da Flask-CORSkütüphaneyi büyük bir başarıyla kullanıyorum. CORS ile iş yapmayı çok kolay ve acısız hale getirir. Aşağıdaki kütüphanenin belgelerinden bazı kodlar ekledim.

yükleme:

$ pip install -U flask-cors

Tüm rotalardaki tüm alanlar için CORS'a izin veren basit bir örnek:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

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

Daha spesifik örnekler için belgelere bakın. Ayrı bir şişe sunucusuna erişmesi gereken bir iyonik uygulamada CORS sorununu çözmek için yukarıdaki basit örneği kullandım.

Kendi tecrübelerime göre, CORS'un neden bir endişe olduğunu basit bir açıklama bulmak zor.

Neden orada olduğunu anladıktan sonra, başlıklar ve tartışma çok daha net hale geliyor. Birkaç satırda denemek istiyorum.

Her şey çerezlerle ilgili. Çerezler bir istemcide kendi alan adlarına göre saklanır.

Örnek bir hikaye: Bilgisayarınızda bir çerez var yourbank.com. Belki oturumunuz oradadır.

Anahtar nokta: İstemci sunucuya istekte bulunduğunda, istemcinin üzerinde bulunduğu etki alanı altında depolanan çerezleri gönderir.

İçin tarayıcınızda oturum açtınız yourbank.com. Tüm hesaplarınızı görmek istiyorsunuz. yourbank.comçerezleri alır ve yanıtını geri gönderir (hesaplarınız).

Başka bir istemci sunucuya çapraz kökenli bir istekte bulunursa , bu çerezler daha önce olduğu gibi gönderilir. Ruh roh.

Siz göz atın malicious.com. Kötü niyetli, dahil olmak üzere farklı bankalara bir sürü istekte bulunur yourbank.com.

Çerezler beklendiği gibi doğrulandığından, sunucu yanıtı yetkilendirir.

Bu çerezler toplanır ve gönderilir - ve şimdi malicious.combir yanıtı var yourbank.

Amanın.

Şimdi birkaç soru ve cevap ortaya çıkıyor:

• "Neden tarayıcının bunu yapmasını engellemiyoruz?" Evet. CORS.
• "Nasıl başaracağız?" Sunucuya CORS'nin uygun olduğunu bildirmesini isteyin.

Aşağıdaki kodu web.config dosyanıza yapıştırmanız yeterlidir.

Aşağıdaki kodu <system.webServer>etiketin altına yapıştırmanız gerekir

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

Access-Control-Allow-Origin yanıt üstbilgisi, yanıtın belirtilen kaynaktan gelen istek koduyla paylaşılıp paylaşılamayacağını belirtir.

Header type Response       header
Forbidden header name      no

Tarayıcıya herhangi bir kaynaktan gelen bir kaynağa erişmesine izin vermesini bildiren bir yanıt aşağıdakileri içerecektir:

Access-Control-Allow-Origin: *

Daha fazla bilgi için burayı ziyaret edin ....

Nginx ve Appache

Apsillers cevabına ek olarak , talebin basit olup olmadığını gösteren wiki grafiği eklemek istiyorum (ve SEÇENEKLER uçuş öncesi isteği gönderilip gönderilmediğini)

Basit bir istek için (örn. Hotlinking görüntüleri ) sunucu yapılandırma dosyalarınızı değiştirmeniz gerekmez, ancak Melvin Guerrero cevabında belirttiği gibi uygulamada (sunucuda barındırılan, örneğin php'de) üstbilgiler ekleyebilirsiniz - ancak unutmayın : tam eklerseniz sunucunuzdaki cors başlıkları (config) ve aynı zamanda uygulamadaki basit cors'a (örneğin php) izin verirseniz bu hiç çalışmaz.

Ve burada iki popüler sunucu için yapılandırmalar

• açmak Nginx üzerinde CORS ( nginx.confdosyası)

  Kod snippet'ini göster

  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;
      }
  }

  Kod snippet'ini çalıştırSonuçları gizle

  Snippet'i genişlet

• açmak appache üzerinde CORS ( .htaccessdosyası)

  Kod snippet'ini göster

  # ------------------------------------------------------------------------------
  # | 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"

  Kod snippet'ini çalıştırSonuçları gizle

  Snippet'i genişlet