302 yönlendirmesi sırasında tarayıcı çerezleri gönderme


88

302 yönlendirmesi sırasında bir çerezi geri göndermede herhangi bir sorun var mı? Örneğin, bir url'ye dönüş çerezi oluşturursam ve kullanıcıyı aynı yanıtla yeniden yönlendirirsem, herhangi bir (modern) tarayıcı çerezi yok sayar mı?


Biraz okuduğumda, oturum değişkenlerinin sunucu tarafında olduklarından ve istemci öngörülebilirliğine bağlı olmadıklarından dolayı çerezlerden daha iyi olacağını düşünüyorum.
ADTC

Yanıtlar:


41

Tarayıcıların çoğu, 302 yönlendirmelerinde çerezleri kabul ediyor. Bundan oldukça emindim ama biraz araştırma yaptım. Tüm modern tarayıcılar değil . Silverlight İstemcisinde artık kaldırılmış / ölü / microsoft connect Q / A'dan İnternet arşiv bağlantısı HTTP Yığını 302 Yönlendirme Yanıtlarında (2010) Set-Cookie'yi yok sayıyor

Sanırım artık IE6 için bir yedeğimiz var ve Windows Mobile tarayıcıları ...


1
Belirttiğiniz forum sayfasına URL ile erişilemez. IE6 ve Windows Mobile tarayıcılarının olmadığını mı söylüyorsunuz?
hiroshi

1
bağlantı taşındı. Tamamen aynı içeriğe sahip yeni bir bağlantı kurdum. ve Mobil eklenti için böcek kendi içinde birtakım IE özel sürümler anlamına geliyordu
regilero

53

Bu blog gönderisine göre: http://blog.dubbelboer.com/2012/11/25/302-cookie.html tüm büyük tarayıcılar, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) hem Windows hem de Mac'te, yönlendirmelerde tanımlama bilgileri ayarlayın. Bu, hem 301 hem de 302 yeniden yönlendirmeleri için geçerlidir.

@Benni'nin belirttiği gibi:

https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies

Bir tanımlama bilgisinin SameSite özniteliği, tanımlama bilgisinin birinci taraf mı yoksa aynı site içeriğiyle mi sınırlandırılacağını belirtir. SameSite'ın birkaç değerine izin verilir:

  • Bir çerez "SameSite=Strict"yalnızca aynı site talebi ile gönderilecektir.
  • "SameSite=Lax"Aynı site isteğiyle veya "güvenli" HTTP yöntemiyle siteler arası üst düzey gezinmeyle birlikte bir çerez gönderilecektir.
  • "SameSite=None"Hem aynı site hem de siteler arası isteklerle birlikte bir çerez gönderilecektir.

Maalesef bu liste Chrome'u içermiyor, bu yüzden tüm büyük tarayıcıları tam olarak söyleyemeyiz ...
MestreLion

3
@MestreLion: Chrome tarayıcımda çalışıyor. Yani .. Sanırım sonunda şimdi, 2019'da işe yaradığını söyleyebiliriz.
Michael

1
Aynı site politikasına bağlıdır: Kesinlikle hala çalışmıyor.
Benni

42

Bir uyarı (geliştiricinin hayatını kurtarmak için):

IE ve Edge, tanımlama bilgisinin etki alanı localhost olduğunda yönlendirme yanıtında Set-Cookie'yi göz ardı ediyor .

Çözüm:

Kullanım 127.0.0.1 yerine localhost .


12
IE ve Edge bunu "düzeltmiş" olabilir, böylece 127.0.0.1 için de çerez ayarlamazlar. Doh! Ve geliştiricilerin neden hepsinin IE'yi sevmediğini merak ediyorlar ... Cevabınız hala benim için yaklaşık 4 saatlik kafa kaşıma ile sonuçlandı. Teşekkürler!
GlenPeterson

19

İşte bu sorun için Chromium hatası (302 durumuyla HTTP yanıtı için set-çerezi yoksayılır).


1
Bu doğruysa, gerçekten kötü bir haber :-(
MestreLion

Sanırım düzelttiler. Hata raporu hala "WontFix" yazıyor, ancak Chrome tarayıcımda çalışıyor.
Michael

@Michael, Chromium'un Chrome olmadığını unutmayın: lifewire.com/chromium-and-chrome-differences-4172101 - bu, Chrome'da çalışabileceği anlamına gelirken, Chromium için mutlaka doğru değildir
Thomas

4

Bu gerçekten hoş karşılanmayan bir yaklaşımdır, ancak gerçekten 30x set-cookie tarayıcı davranışına güvenmek istemiyorsanız meta http-equiv="refresh", çerezi ayarlarken bir HTML "yönlendirmesi" kullanabilirsiniz . Örneğin, PHP'de:

<?php
    ...
    setcookie("cookie", "value", ...);
    url="page.php";
?>
<html>
<head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head>
<body><a href="<?=$url?>">Continue...</a></body>
</html>

Sunucu, uygun bir 300x yönlendirme yerine 200 ile Set-Cookie gönderecektir, böylece tarayıcı çerezi saklayacak ve ardından "yeniden yönlendirme" işlemini gerçekleştirecektir. <a>Bağlantı meta yenilemeyi yapmaz durum tarayıcıda bir geri dönüş olduğunu.


3

Bu sorunla hem Firefox hem de Safari'de karşılaştım, ancak Chrome'da değil. Testlerime göre, bu yalnızca yönlendirme sırasında alan değiştiğinde gerçekleşir. Bu, OAuth2 akışında tipiktir:

  1. OAuth2 kimlik sağlayıcısı (GitHub, Twitter, Google), tarayıcıyı tekrar uygulamanıza yönlendirir
  2. Uygulamanızın geri arama URL'si yetkilendirmeyi doğrular ve giriş çerezlerini ayarlar, ardından hedef URL'ye yeniden yönlendirme yapar.
  3. Hedef URL'niz herhangi bir çerez ayarlanmadan yüklenir.

Henüz anlamadığım nedenlerden dolayı, talep 2'deki bazı çerezler göz ardı edilirken diğerleri yok. Bununla birlikte, istek 2, Refreshbaşlık içeren bir HTTP 200 döndürürse ("meta yenileme" yönlendirmesi), tanımlama bilgileri istek 3'e göre doğru şekilde ayarlanır.


1
Bu yanlış geri arama sorunlarının sebebinin olduğundan şüpheleniyorum samesite=strict. Geri arama isteği için, tarayıcı yine de oluşturanın google (veya hangi sağlayıcıyı kullanırsanız kullanın) olduğunu düşünüyor. Dolayısıyla, 302 yanıtınızda bir samesite = katı çerez ayarlarsanız, tarayıcı muhtemelen "ah ha! Bu, Google'dan sitenize gelen siteler arası bir istek" olarak düşünür ve bu nedenle, yeniden yönlendirilen url'yi isterken çerezi göndermez. Düzeltme, yaptığınız gibi bir meta yenileme kullanmaktır, böylece isteğiniz kendi sitenizden gelir. Saçmalıyor olabilirim, ama şu anki düşüncem bu.
Ilan

2

.Net üzerinde OpenIdConnect / IdentityServer kullanılırken bu sorunla karşılaşıldı, burada ayrı bir API (farklı ana bilgisayar adı) kimlik doğrulamayı işliyor ve ana siteye yeniden yönlendiriyor.

Öncelikle (localhost üzerinde geliştirme için) CookieSecureseçeneği güvenli olmamak için SameAsRequestveya bununla Neverbaşa çıkmak için ayarlamanız gerekir http://localhost/. Michael Freidgeim'in cevabına bakın .

İkinci olarak, CookieSameSiteözelliği olarak ayarlamanız gerekir Lax, aksi takdirde çerezler hiç kaydedilmez. Strictburada çalışmıyor!


-1

Benim durumumda CookieOptions.Secure = true ayarladım , ancak http: // localhost . Üzerinde test ettim ve tarayıcı, ayara göre çerezleri gizledi .

Bu tür bir sorunu önlemek için, protokol Request.IsHttps ile eşleşecek şekilde cookie Secure seçeneğini belirleyebilirsiniz, örn.

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }

2
Bu durumda güvenli bayrağı ayarlamayın . Bayrağın tüm amacı, tarayıcıya yalnızca HTTPS üzerinden bağlanırken çerezi kullanmasını söylemektir. İşaretin koşullu olarak ayarlanması semantiği bir şekilde değiştirir ve HTTPS -> HTTP'den geçiş yapan çerezi kaybedersiniz, ancak HTTP -> HTTPS'den geçerken değil. Ancak tüm bunlar, tarayıcıların Set-Cookie302 yönlendirmelerinde başlıklarla yaptıklarına ortogonaldir .
Martijn Pieters

1
O zaman -3 oyla cevap sorunu çözer. Secure = true ayarlıyordum, ancak localhost'ta test etmek için sadece http kullandığımı unuttum. Noob hatası. secure=request.is_secureŞişede kullanın .
Eloff
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.