- Konu sahibi
- #1
HTTP OPTIONS, bir istemcinin sunucuya belirli bir kaynağın veya sunucunun hangi HTTP yöntemlerini desteklediğini sormasını sağlayan HTTP metodudur. İletişim seçeneklerini sorgular; veri kaynağını okumak veya değiştirmek için kullanılmaz. CORS ön kontrolü bunun tarayıcıların otomatik başlattığı önemli bir kullanım alanıdır; her OPTIONS isteği CORS değildir. Geliştirici olarak göreviniz, sunucunun bu isteğe doğru durum kodu ve başlıklarla yanıt vermesini sağlamaktır.
İstemci, hedef kaynağa OPTIONS isteği gönderir. Sunucu başarılı bir yanıt verirse desteklenen yöntemleri
Sunucunun yanıtı da CORS için uygun
Kaynak yolu yerine OPTIONS * hedefi kullanılırsa sorgu sunucunun geneline ilişkindir; bütün uç noktaların eksiksiz API envanterini döndürmek zorunda değildir. Örneğin bir kaynağın Allow yanıtı, başka bir yolun aynı yöntemleri desteklediğini kanıtlamaz. Genel OPTIONS yanıtı HTTP önbelleğine alınabilir bir kaynak yanıtı değildir; tarayıcının ayrı CORS preflight önbelleğini bununla karıştırmayın.
Aşağıdaki komut,
Başarılı bir CORS yanıtında en azından istenen origin'i ve yöntemi kapsayan izin başlıklarını görmeyi beklersiniz. Örneğin yanıt mantıksal olarak şunları içerebilir:
İsteği uygularken şu sırayı izleyin:
Bu kavramlar birbirine yakın görünse de aynı şeyi ifade etmez:
Örneğin
OPTIONS isteğini yan etkili kayıt oluşturma koduna yönlendirmek hatadır. CORS ön kontrolünde gövde veya kimlik doğrulama işlemi beklemek yerine, yalnızca güvenilir origin, yöntem ve başlık politikalarını doğrulayıp uygun yanıtı döndürün. Ters proxy OPTIONS isteğini uygulamaya ulaşmadan engelliyorsa uygulamadaki düzeltme etkisiz kalabilir; bu durumda ağ geçidi ve proxy yapılandırması da kontrol edilmelidir.
Bir diğer hata,
Nasıl çalışır?
İstemci, hedef kaynağa OPTIONS isteği gönderir. Sunucu başarılı bir yanıt verirse desteklenen yöntemleri
Allow başlığıyla bildirebilir. Tarayıcılar, farklı bir origin'e yapılacak bazı isteklerden önce CORS ön kontrolü (preflight) amacıyla da OPTIONS kullanır. Bu istekte genellikle şu başlıklar bulunur:Origin: İsteği yapan web uygulamasının origin'i.Access-Control-Request-Method: Asıl istekte kullanılacak yöntem.Access-Control-Request-Headers: Asıl istekte gönderilecek özel başlıklar.
Sunucunun yanıtı da CORS için uygun
Access-Control-Allow-Origin, Access-Control-Allow-Methods ve gerekiyorsa Access-Control-Allow-Headers başlıklarını içermelidir. Tarayıcı bu yanıtı yeterli bulmazsa asıl isteği göndermeyebilir. Tarayıcıda preflight varsa önce bu yanıtı inceleyin. Ön kontrol gerektirmeyen bir GET isteğinde de asıl yanıttaki izin başlıkları eksikse CORS hatası oluşabilir.Kaynak yolu yerine OPTIONS * hedefi kullanılırsa sorgu sunucunun geneline ilişkindir; bütün uç noktaların eksiksiz API envanterini döndürmek zorunda değildir. Örneğin bir kaynağın Allow yanıtı, başka bir yolun aynı yöntemleri desteklediğini kanıtlamaz. Genel OPTIONS yanıtı HTTP önbelleğine alınabilir bir kaynak yanıtı değildir; tarayıcının ayrı CORS preflight önbelleğini bununla karıştırmayın.
| Öğe | Görevi | Nerede görülür? |
|---|---|---|
| OPTIONS | Sunucuya yetenek veya izin bilgisi sormak için kullanılan HTTP metodu | İstek satırında |
| Allow | Kaynakta desteklenen HTTP yöntemlerini bildiren yanıt başlığı | Sunucu yanıtında |
| CORS başlıkları | Tarayıcıların farklı origin isteklerine izin verilip verilmediğini belirler | Özellikle preflight yanıtında |
Somut bir test örneği
Aşağıdaki komut,
https://example.com/api/items kaynağına bir CORS ön kontrolü benzetir. example.com burada yalnızca örnek alan adıdır.
Bash:
curl -i -X OPTIONS https://example.com/api/items \
-H "Origin: https://app.example.com" \
-H "Access-Control-Request-Method: POST" \
-H "Access-Control-Request-Headers: Content-Type, Authorization"Başarılı bir CORS yanıtında en azından istenen origin'i ve yöntemi kapsayan izin başlıklarını görmeyi beklersiniz. Örneğin yanıt mantıksal olarak şunları içerebilir:
Kod:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization204 No Content yaygın ve uygun bir sonuçtur; ancak başarılı OPTIONS yanıtı yalnızca bu durum koduyla sınırlı değildir. 200 gibi başka başarılı bir durum kodu da gövdesiz veya kısa bir yanıtla kullanılabilir. Önemli olan, sunucunun izinleri doğru başlıklarla bildirmesidir.İsteği uygularken şu sırayı izleyin:
- API uç noktasının OPTIONS isteğini kabul ettiğinden emin olun.
- İsteğin
OriginveAccess-Control-Request-Methodbaşlıklarını göndererek testi çalıştırın. - Yanıtta beklenen CORS başlıklarını ve başarılı bir durum kodunu kontrol edin.
- Başlıklar eksikse CORS ayarını uygulama, ters proxy veya web sunucusu katmanında düzeltin.
- Tarayıcı geliştirici araçlarında OPTIONS isteğini yeniden inceleyip ardından asıl isteğin gönderilip gönderilmediğini kontrol edin.
OPTIONS, Allow ve CORS arasındaki fark
Bu kavramlar birbirine yakın görünse de aynı şeyi ifade etmez:
Örneğin
Allow: GET, POST, OPTIONS bulunması, kaynağın bu yöntemleri desteklediğini bildirir; tek başına başka bir origin'den gelen tarayıcı isteğine izin verildiği anlamına gelmez. CORS izinleri ayrıca ilgili Access-Control-Allow-* başlıklarıyla değerlendirilir.Sık yapılan hatalar
OPTIONS isteğini yan etkili kayıt oluşturma koduna yönlendirmek hatadır. CORS ön kontrolünde gövde veya kimlik doğrulama işlemi beklemek yerine, yalnızca güvenilir origin, yöntem ve başlık politikalarını doğrulayıp uygun yanıtı döndürün. Ters proxy OPTIONS isteğini uygulamaya ulaşmadan engelliyorsa uygulamadaki düzeltme etkisiz kalabilir; bu durumda ağ geçidi ve proxy yapılandırması da kontrol edilmelidir.
Bir diğer hata,
Allow başlığını CORS izni sanmaktır. Ayrıca izin verilen origin'i gereksiz biçimde herkese açmak, özellikle kimlik bilgisi taşıyan isteklerde yanlış bir yapılandırma oluşturabilir. İzinleri uygulamanın gerçekten kullandığı origin, yöntem ve başlıklarla sınırlayın.