Subdomain.example.com example.com tarafından okunabilecek bir çerez ayarlayabilir mi?

Bunun belirlenmesinin çok zor olduğuna inanamıyorum.

RFC'leri okumamıza rağmen, subdomain.example.com adresindeki bir sunucunun example.com tarafından okunabilecek bir tanımlama bilgisi ayarlayıp sağlayamayacağı açık değildir.

subdomain.example.com, Domain özelliği .example.com olan bir çerez ayarlayabilir. RFC 2965 açıkça böyle bir çerezin example.com'a gönderilmeyeceğini açıkça belirtmiş görünmektedir, ancak daha sonra eğer Domain = example.com olarak ayarladıysanız,. Birlikte ele alındığında, example.com döndürürse Domain = example.com ile bir çerez oluşturduğunda, o çerezleri geri alamayacağı anlaşılıyor! Bu doğru olamaz.

Kuralların gerçekte ne olduğunu netleştiren var mı?

Okuduğunuz aynı RFC2109’dan alıntı :

       * Etki Alanı için istek ana bilgisayarından x.foo.com'dan bir Set-Cookie = .foo.com
         kabul edildi.

Böylece subdomain.example.combir çerez ayarlayabilirsiniz .example.com. Çok uzak çok iyi.

       Uygulanabilir çerez-değerlerinin seçilmesinde aşağıdaki kurallar geçerlidir
       Kullanıcı aracısının sahip olduğu tüm çerezler arasında.

       Alan Seçimi
            Kaynak sunucunun tam nitelikli ana bilgisayar adı etki alanı eşleşmeli
            Çerezin Domain niteliği

Peki, etki alanı eşleştirmemiz var mı?

   * A, bir FQDN dizesidir ve N'nin boş olmayan bir isim olduğu NB formuna sahiptir.
     dize, B, B biçimine sahiptir ve B ', bir FQDN dizesidir. (Yani, xycom
     etki alanı .y.com ile eşleşiyor, ancak y.com ile eşleşmiyor.)

Ama şimdi tanımına göre example.cometki alanı eşleşmez .example.com. Ancak www.example.com(veya etki alanındaki herhangi bir "boş olmayan isim"). Bu RFC, teoride teorik olarak RFC2965 tarafından kullanılmakta ve bu, Set-Cookie2işlemlerdeki alanlar için öncü bir noktayı zorlamakla ilgili şeyleri dikte etmektedir.

Daha da önemlisi, @Tony tarafından belirtildiği gibi gerçek dünyadır. Gerçek kullanıcı aracısının ne yaptığını bir bakış için, bkz.

Firefox 3'ün nsCookieService.cpp

ve

Chrome'un cookie_monster.cc

Gerçek siteler ne yaptığını içine perspektifi için, birlikte oynamayı deneyin wgetkullanarak --save-cookies, --load-cookiesve --debugne olup bittiğini görmek için.

Aslında, çoğu sitenin Set-Cookieeski RFC özelliklerinden "Host" değerlerine sahip bir kombinasyon kullandığını , dolaylı olarak bir öncü nokta olmadan ( twitter.com'un yaptığı gibi) veya Etki Alanı değerlerini (öncü bir nokta ile) ayarlayıp yeniden yönlendirmeyi kullandığını göreceksiniz. gibi bir sunucuya www.example.com( google.com gibi).

Eğer tarayıcı bu noktada yapması gereken herhangi bir modern tarayıcının yapması gereken RFC 6265'i uygularsa , o zaman ayarlanan bir çerez .example.comöndeki noktayı göz ardı eder (bölüm 5.2.3) ve bu çerez daha sonra çıplak etki alanına ve tümüne gönderilir. alt etki alanları.

Eski tarayıcılardan gelen önemli trafik varsa, bu davranışa güvenmeyin; bu RFC sadece 2011 yılına kadar uzanıyor.

Bu mümkün olmamalı. Ancak, dediğiniz gibi, bu yaygın olarak belgelendirilmiş bir standart olmadığından, hangi yazılımı kullandığınıza bağlıdır.

Çoğu modern tarayıcı tanımlanmış bir "web güvenliği modeline" uyar. Bu model, tarayıcıların güvenlik konusundaki davranışını, çerezler gibi konularda (özellikle belirli bir web sitesine nasıl geri gönderileceğini) etkin bir şekilde yönetir. Model ayrıca, "tarayıcıların kendilerini ayarlamayan etki alanı adlarına çerez göndermediği" kuralına da sahiptir.

Söylenen, domain.com js.domain.com için çerezleri ayarlayabilmelidir. Ancak, js.domain.com, yalnızca kendisi için çerezleri ayarlayabilir. Ancak bunların tümü kullandığınız tarayıcıya bağlı.