Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 7 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi
Laravel'de CORS ayarı, API'ye istek gönderen frontend alan adını açıkça izin verilen origin listesine ekleyerek yapılır. Projede config/cors.php dosyası varsa aşağıdaki gibi düzenleyin; dosya yoksa önce projenizin sürümünü doğrulayın. Laravel 12 örneğinde php artisan config:publish cors komutu dosyayı yayınlar. Eski projelerde aynı komutun var olduğunu varsaymayın; CORS middleware ve yapılandırma yöntemi sürüme göre kontrol edilmelidir. Bu örnek token kullanan bir API için sınırlı başlangıç ayarıdır; tüm projelere uygulanacak hazır güvenlik politikası değildir.

PHP:
<?php

return [
    'paths' => ['api/*'],

    'allowed_methods' => ['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'OPTIONS'],

    'allowed_origins' => [
        'http://localhost:3000',
        'https://example.com',
    ],

    'allowed_origins_patterns' => [],

    'allowed_headers' => ['Content-Type', 'X-Requested-With', 'Authorization', 'Accept'],

    'exposed_headers' => [],

    'max_age' => 0,

    'supports_credentials' => false,
];

Yapılandırmayı uygulama ve kontrol sırası​

  1. Frontend'in gerçek adresini allowed_origins içine şema ve portuyla birlikte ekleyin. Örneğin http://localhost:3000 ile http://localhost:5173 farklı origin değerleridir.
  2. API rotalarınız api/* dışında bir prefix kullanıyorsa paths listesine ekleyin. CORS ayarı yalnızca eşleşen yollar için uygulanır. Origin listesi API için bir kimlik doğrulama veya ağ erişim sınırı değildir; tarayıcı dışı istemciler de API'ye istek gönderebilir.
  3. İhtiyaç duyulan HTTP metotlarını ve istemcinin gönderdiği başlıkları allowed_methods ve allowed_headers içinde belirtin.
  4. Terminalde php artisan config:clear çalıştırın. Üretimde yapılandırma önbelleği kullanıyorsanız ardından php artisan config:cache çalıştırın.
  5. Tarayıcı geliştirici araçlarında önce OPTIONS isteğini, sonra asıl API isteğini kontrol edin. OPTIONS yanıtında uygun CORS başlıkları bulunmalı ve hata durumunda sunucu yanıtı ayrıca incelenmelidir.

CORS nasıl çalışır?​


Tarayıcı, farklı origin'e yapılan basit olmayan isteklerden önce çoğunlukla OPTIONS yöntemiyle bir preflight isteği gönderir. Bu istekte kullanılacak metot ve başlıklar sorulur. Sunucu izin verirse asıl GET, POST veya başka bir istek gönderilir. Yanıt başlıklarının gönderilmesi, tarayıcının bu yanıtı JavaScript'e açacağı anlamına gelir; CORS tek başına kimlik doğrulama veya yetkilendirme sağlamaz.

Örneğin frontend https://example.com, API ise https://api.example.com olsun. Frontend Authorization başlığıyla POST /api/orders çağrısı yapıyorsa allowed_origins içinde frontend origin'i, allowed_methods içinde POST, allowed_headers içinde de Authorization bulunmalıdır.
AyarNe için kullanılırÖrnek karar
allowed_originsYanıtı okuyabilecek origin'lerÜretimde yalnızca gerçek frontend alan adı
allowed_methodsİzin verilen HTTP metotlarıAPI'nin gerçekten kullandığı metotlar
allowed_headersİstemcinin gönderebileceği başlıklarContent-Type, Authorization
supports_credentialsCookie veya oturum bilgisinin taşınmasıCookie kullanılıyorsa true
Cookie veya oturum tabanlı kimlik doğrulama kullanıyorsanız supports_credentials değerini true yapın ve allowed_origins içinde * kullanmayın; gerçek origin'i açıkça yazın. Ayrıca frontend istemcisinin isteği credentials seçeneğiyle göndermesi gerekir. Sanctum SPA akışında ilgili csrf-cookie yolu, X-XSRF-TOKEN başlığına izin, stateful API ve oturum çerezi ayarları da birlikte kontrol edilmelidir; burada verilen token örneği o kurulumun tamamı değildir. Bearer token kullanan API'lerde çoğu durumda supports_credentials gerekmeyebilir.

Preflight yanıtını ayrı okuyun​

Aşağıdaki temsilî adresi kendi mevcut API uç noktanızla değiştirin. Komut OPTIONS yanıtını gösterir; sipariş oluşturan POST isteğini göndermez:
Bash:
curl -i -X OPTIONS 'https://api.example.com/api/orders' -H 'Origin: https://example.com' -H 'Access-Control-Request-Method: POST' -H 'Access-Control-Request-Headers: authorization,content-type'
Yanıtta izin verilen origin, yöntem ve başlıkları kontrol edin. curl tarayıcının CORS politikasını uygulamaz; başlık incelemesi gerçek frontend testinin yerine geçmez. Preflight başarılı olsa bile asıl isteğin kimlik doğrulama veya uygulama hatası ayrıca olabilir.

Sık yapılan hatalar​

  1. Origin'e yalnızca alan adını yazmak: https://example.com ile example.com aynı değer değildir. Şema ve port korunmalıdır.
  2. Yanlış path tanımlamak: CORS ayarı api/* için yazılmışken istekler v1/* yoluna gidiyorsa başlıklar eklenmez.
  3. OPTIONS isteğini engellemek: Web sunucusu, proxy veya uygulama katmanı OPTIONS isteğine 404, 405 ya da 401 döndürüyorsa preflight başarısız olur.
  4. Yapılandırma önbelleğini unutmak: Dosyayı değiştirdiğiniz halde eski ayarlar okunuyorsa önce config:clear ile önbelleği temizleyin.
  5. Sorunu yalnızca Laravel'de aramak: Tarayıcı geliştirici araçlarında yanıt başlıklarını, HTTP durum kodunu ve isteğin gerçekten hangi origin'den çıktığını birlikte kontrol edin.

Sık sorulan sorular​

Aynı CORS başlığı neden iki kez görünüyor?​

Laravel ile proxy veya web sunucusu aynı başlığı ayrı ayrı ekliyor olabilir. Access-Control-Allow-Origin birden fazla bağımsız değerle dönerse tarayıcı yanıtı reddedebilir. Başlığı hangi katmanın ürettiğini belirleyin ve birbirinden habersiz iki kural bırakmayın.

Dinamik origin yanıtında önbellek için neye bakılır?​

İzinli origin'e göre farklı yanıt üretiliyorsa Vary: Origin bilgisinin ve proxy/CDN önbellek politikasının uygunluğunu kontrol edin. Bir origin için hazırlanmış yanıtın başka istemciye yanlışlıkla sunulmaması gerekir. Cache katmanını düzeltmek için origin listesini genişletmeyin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic