Unkillable cookie (klasik ASP3, PHP5, IIS5, FF3.5, IE8)

2 Cevap php

Ben klasik ASP silmek gerekiyor, sonra PHP bir çerez üreten bir sistemi var. Bu kirli hızlı-ve-dev kutu, IIS5, PHP5 ve ASP3 çalışan sadece bir yedek XP makinedir. Ben sürecin diğer parçaları localhost ile çalışmak olmaz çünkü sahte etki alanı adı (www.localtest.com) oluşturmak için hosts dosyasını kullanılır.

PHP dosyası site köküne kapalı bir alt olduğunu, ancak çerez etki alanıdır. Localtest.com ve yolu (/) köküdür. Çerez adı "authkey" ve değeri 32 bayt hashCode olduğunu.

ASP dosyası (şimdilik) site köküne bulunmaktadır. PHP onu oluşturur gayet sonra çerezi okuyabilir, ama ne olursa olsun ben denemek ne de tüm ASP çerez değiştirmek için görünmüyor olabilir - bu değeri değiştirmek şöyle dursun, sona erme değişmez. Firefox 3.5 ve IE 8 Hem (onlar sonunda bir şey üzerinde anlaşma yaparken, bu olacağını rakamlar) yaptığım her girişimi görmezden.

Ben pek çok varyasyon denedim - (çeşitli biçimlerde değerlerin çok çeşitli) sadece sona erme ayarı, tam olarak tüm bir Set-Cookie başlığını yayma Response.AddHeader kullanarak, sona erme hariç çerez maç için tüm parametreleri ayarlayarak false değeri ve başarısız diğer bazı dize değerini değiştirmek için sonra nihayet sadece bir girişim, ayarı bu varyasyonlar.

Ne halt oluyor? Bu "sahte" bir etki ile çalışan bazı ASP yan etkisi var mı? Ben (garibi) bir çerez silmek için fırsat vardı hiç rağmen ben, ASP, ana-belirtilen etki ile herhangi bir sorun görmeden 10 + yıldır bu şekilde geliştirdik.

Ben bile değerini ayarlamak olamayacağını özellikle şaşırdım.

2 Cevap

Tuhaf.

Sorun etki alanı adı lider nokta oldu. Benim site alt etki alanları kullanarak değil çünkü ben gerçekten gerek yok - ama bu nokta orada görünüşte ise, tarayıcılar silmek veya tanımlama değişmez.

Ben sistemlerinin bir yeri (örneğin DUYURU gibi) sub-domain-nötr tanımlama yapmak için o güvenmek beri biliyoruz ki, yeni bir davranış olmadığını merak ediyorum.

Ayrıca, ben her şeyi belirtmek zorunda çerezi silmek için - alanı, yol, ve tarih, ama bu RFC başına aslında düşünüyorum ben bu konuda çok endişeli değilim.

Sunucu teknolojisi sürece doğru HTTP başlıklarını gönderiliyor gibi, önemli değil - Fiddler veya fiili HTTP trafiği bakmak benzer kullanın. Herhalde onlar değil, ancak HTTP akışı bakmak sürece emin olamayız.

(Normalde Wireshark tavsiye ederim, ancak istemci ve sunucu aynı makine üzerinde olduğunda bu işe yaramazsa.)