Yanıtlar:
Mevcut çerez belirtimi, RFC 2109 ve RFC 2965'in yerini alan RFC 6265'tir (her iki RFC de artık "Tarihi" olarak işaretlenmiştir) ve çerezlerin gerçek dünyadaki kullanımları için sözdizimini resmileştirir. Açıkça şunu belirtmektedir:
- Giriş
...
Tarihsel nedenlerle, çerezler bir dizi güvenlik ve gizlilik hata içerir. Örneğin, sunucu belirli bir çerezin "güvenli" bağlantılar için tasarlandığını belirtebilir, ancak Secure özniteliği etkin bir ağ saldırganının varlığında bütünlük sağlamaz. Benzer şekilde, web tarayıcıları tarafından kullanılan olağan "aynı kökenli politika" farklı bağlantı noktaları üzerinden alınan içeriği yalıtsa da, belirli bir ana bilgisayarın çerezleri o ana bilgisayardaki tüm bağlantı noktaları arasında paylaşılır.
Ve ayrıca:
8.5. Zayıf Gizlilik
Çerezler, bağlantı noktasıyla yalıtım sağlamaz . Tanımlama bilgisi bir bağlantı noktasında çalışan bir hizmet tarafından okunabilirse, tanımlama bilgisi aynı sunucunun başka bir bağlantı noktasında çalışan bir hizmet tarafından da okunabilir. Çerez bir bağlantı noktasındaki bir hizmet tarafından yazılabilirse, aynı sunucudaki başka bir bağlantı noktasında çalışan bir hizmet tarafından da yazılabilir. Bu nedenle, sunucular aynı ana bilgisayarın farklı bağlantı noktalarında karşılıklı güvensiz hizmetler çalıştırmamalı ve güvenliğe duyarlı bilgileri depolamak için çerezleri KULLANMAMALIDIR.
RFC2965 3.3.1'e göre (tarayıcılar tarafından takip edilip edilmeyebilir veya izlenmeyebilir ), bağlantı noktası üstbilginin portparametresi aracılığıyla açıkça belirtilmedikçe Set-Cookie, çerezler herhangi bir bağlantı noktasına gönderilebilir veya gönderilmeyebilir.
Google'ın Tarayıcı Güvenliği El Kitabı : varsayılan olarak, çerez kapsamı geçerli ana bilgisayar adındaki tüm URL'lerle sınırlıdır ve bağlantı noktası veya protokol bilgilerine bağlı değildir. ve bazı satırlar Daha sonra çerezleri yalnızca tek bir DNS adıyla sınırlamanın bir yolu yoktur [...] aynı şekilde, onları belirli bir bağlantı noktasıyla sınırlamanın bir yolu yoktur. (Ayrıca, IE onun aynı kaynak politikası içine değil faktör noktası numaralarını yaptığı, akılda tutmak hiç .)
Bu nedenle, burada iyi tanımlanmış herhangi bir davranışa güvenmek güvenli görünmüyor.
Bu gerçekten eski bir soru ama kullandığım bir geçici çözüm ekleyeceğimi düşündüm.
Dizüstü bilgisayarımda çalışan iki hizmetim var (biri 3000 numaralı bağlantı noktasında ve diğeri 4000 numaralı bağlantı noktasında). ( http://localhost:3000Ve http://localhost:4000) arasına atladığımda , Chrome aynı çerezi geçecekti, her hizmet çerezi anlamayacak ve yeni bir tane oluşturmayacaktı.
Eriştiğimde http://localhost:3000ve http://127.0.0.1:4000Chrome'un localhost için bir çerez ve 127.0.0.1 için bir çerez tuttuğu için sorunun ortadan kalktığını fark ettim .
Yine, kimse bu noktada bakım olabilir ama benim durumum için kolay ve yararlı oldu.
localhostpaylaşılamaz 127.0.0.1veya tam tersi olamaz . Ancak bağlantı noktasına bakılmaksızın aynı ana makine / alan adındaki çerezler paylaşılabilir.
Bu çerez SOP (Aynı Köken Politikası) büyük bir gri alandır.
Teorik olarak, etki alanında bağlantı noktası numarasını belirtebilirsiniz ve çerez paylaşılmaz. Pratikte, bu birkaç tarayıcıda işe yaramaz ve başka sorunlarla karşılaşırsınız. Bu, yalnızca siteleriniz herkes için uygun değilse ve hangi tarayıcıların kullanılacağını kontrol edebiliyorsanız mümkündür.
Daha iyi bir yaklaşım, aynı IP için 2 alan adı almak ve çerezler için bağlantı noktası numaralarına dayanmamaktır.
Sorunu çözmenin alternatif bir yolu, oturum çerezinin adının bağlantı noktasıyla ilgili olmasını sağlamaktır. Örneğin:
Kodunuz, sunucunuzun hangi bağlantı noktasını kullandığını bulmak için web sunucusu yapılandırmasına erişebilir ve buna göre çerezi adlandırabilir.
Uygulamanızın her iki çerezi alacağını ve bağlantı noktanıza karşılık gelen çerez istemeniz gerektiğini unutmayın.
Çerez adında tam bağlantı noktası numarasına sahip olmanıza gerek yoktur, ancak bu daha uygundur.
Genel olarak, çerez adı, kullandığınız sunucu örneğine özgü herhangi bir parametreyi kodlayabilir, böylece doğru bağlam tarafından kodu çözülebilir.
Aynı makinede iki farklı Django uygulamasını çalıştırırken (ve hata ayıklamaya çalışırken) benzer bir sorun yaşıyordum.
Onları şu komutlarla çalıştırıyordum:
./manage.py runserver 8000
./manage.py runserver 8001
Birincisine giriş yaptıktan sonra ikincisine her zaman ilkini ve viceversa'yı kapattım.
Bunu / etc / hostsime ekledim
127.0.0.1 app1
127.0.0.1 app2
Sonra iki uygulamayı şu komutlarla başlattım:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Sorun çözüldü :)
127.0.0.1:8000, biri için localhost:8000belki bir saniye, ve ::1:8000(belki [::1]:8080hiç hosts dosyasını dokunmak zorunda kalmadan) üçüncü için.
::1 app1 app2 app3 app4 app5 appN
İsteğe bağlı.
Bağlantı noktası belirtilebilir, böylece çerezler bağlantı noktasına özgü olabilir. Gerekli değildir, web sunucusu / uygulaması bununla ilgilenmelidir.
Kaynak: Alman Wikipedia makalesi , RFC2109 , Bölüm 4.3.1
Portparametreyi ortadan kaldırırSet-Cookie(çünkü neredeyse hiç kimse uygulamada gerçekte kullanmamıştır) ve aynı ana bilgisayardaki çerezlerin artık bağlantı noktaları tarafından ayırt edilemeyeceğini açıkça ortaya koymaktadır.