Bir giriş sayfasına yeniden yönlendirilirken doğru HTTP durum kodu nedir?


133

Bir kullanıcı oturum açmadığında ve oturum açmayı gerektiren bir sayfaya erişmeye çalıştığında, oturum açma sayfasına yönlendirme için doğru HTTP durum kodu nedir?

Soruyorum çünkü W3C tarafından belirlenen 3xx yanıt kodlarından hiçbiri gereksinimleri karşılamıyor gibi görünüyor :

10.3.1 300 Çoklu Seçenek

İstenen kaynak, her biri kendi özel konumuna sahip olan bir dizi temsilden herhangi birine karşılık gelir ve aracıya dayalı görüşme bilgileri (bölüm 12), kullanıcının (veya kullanıcı aracısının) tercih edilen bir gösterimi seçebilmesi ve onu yeniden yönlendirebilmesi için sağlanır. o konuma istek.

Bir HEAD talebi olmadığı sürece, yanıt, kullanıcı veya kullanıcı aracısının en uygun olanı seçebileceği kaynak özelliklerinin ve konumların bir listesini içeren bir varlık içermelidir ÖNERİ. Varlık formatı, İçerik Türü başlık alanında verilen ortam türü tarafından belirlenir. Formatına ve yeteneklerine bağlı olarak

kullanıcı aracısı, en uygun seçimin seçimi otomatik olarak YAPILABİLİR. Bununla birlikte, bu spesifikasyon, bu tür otomatik seçim için herhangi bir standart tanımlamaz.

Sunucunun tercih edilen bir temsil seçeneği varsa, Konum alanına bu gösterim için belirli URI'yi dahil etmesi GEREKİR; kullanıcı aracıları, otomatik yeniden yönlendirme için Konum alanı değerini KULLANABİLİR. Aksi belirtilmedikçe bu yanıt önbelleğe alınabilir.

10.3.2 301 Kalıcı Olarak Taşındı

İstenen kaynağa yeni bir kalıcı URI atanmıştır ve bu kaynağa ileride yapılacak başvurular, döndürülen URI'lardan birini kullanmalıdır. Bağlantı düzenleme yeteneklerine sahip istemciler, istek URI'sine olan başvuruları, mümkün olduğunda, sunucu tarafından döndürülen yeni referanslardan bir veya daha fazlasına otomatik olarak yeniden bağlamalıdır. Aksi belirtilmedikçe bu yanıt önbelleğe alınabilir.

Yeni kalıcı URI, yanıttaki Konum alanı tarafından verilmelidir. İstek yöntemi HEAD olmadıkça, yanıtın varlığı yeni URI (lar) a köprü içeren kısa bir köprü metni notu İÇERMELİDİR.

GET veya HEAD dışındaki bir isteğe yanıt olarak 301 durum kodu alınırsa, kullanıcı aracısı, talebin gönderildiği koşulları değiştirebileceğinden, kullanıcı tarafından onaylanmadıkça isteği otomatik olarak yeniden yönlendirmemelidir * ZORUNLU *.

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

10.3.3 302 Bulunan

İstenen kaynak geçici olarak farklı bir URI altında bulunuyor. Yeniden yönlendirme zaman zaman değiştirilebileceğinden, istemcinin gelecekteki istekler için İstek-URI'sini kullanmaya devam etmesi GEREKİR. Bu yanıt, yalnızca Cache-Control veya Expires başlık alanıyla belirtilirse önbelleğe alınabilir.

Geçici URI'nin yanıttaki Konum alanı tarafından verilmesi GEREKİR. İstek yöntemi HEAD olmadıkça, yanıtın varlığı yeni URI (lar) a köprü içeren kısa bir köprü metni notu İÇERMELİDİR.

GET veya HEAD dışındaki bir isteğe yanıt olarak 302 durum kodu alınırsa, kullanıcı aracısı, talebin gönderildiği koşulları değiştirebileceğinden, kullanıcı tarafından onaylanmadıkça isteği otomatik olarak yeniden yönlendirmemelidir * ZORUNLU *.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it

orijinal istek yönteminden bağımsız olarak Konum alanı değerinde bir GET gerçekleştiren bir 303 yanıtıydı. İstemciden ne tür bir tepki beklendiğini açık bir şekilde açıklığa kavuşturmak isteyen sunucular için 303 ve 307 durum kodları eklenmiştir.

10.3.4 303 Diğerlerini Gör

Talebe verilen yanıt farklı bir URI altında bulunabilir ve bu kaynakta bir GET yöntemi kullanılarak alınmalıdır. Bu yöntem, öncelikle POST ile etkinleştirilmiş bir komut dosyasının çıktısının kullanıcı aracısını seçilen bir kaynağa yeniden yönlendirmesine izin vermek için vardır. Yeni URI, başlangıçta talep edilen kaynak için bir ikame referans değildir. 303 yanıtı önbelleğe ALINMAMALIDIR, ancak ikinci (yeniden yönlendirilen) isteğe verilen yanıt önbelleğe alınabilir.

Farklı URI, yanıttaki Konum alanı tarafından VERİLMELİDİR. İstek yöntemi HEAD olmadıkça, yanıtın varlığı yeni URI (lar) a köprü içeren kısa bir köprü metni notu İÇERMELİDİR.

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

10.3.5 304 Değiştirilmedi

İstemci koşullu bir GET isteği gerçekleştirdiyse ve erişime izin veriliyorsa, ancak belge değiştirilmediyse, sunucu bu durum koduyla yanıt VERMELİDİR. 304 yanıtı bir mesaj gövdesi İÇERMEMELİDİR ve bu nedenle her zaman başlık alanlarından sonraki ilk boş satırla sonlandırılır.

Yanıt aşağıdaki başlık alanlarını İÇERMELİDİR:

  - Date, unless its omission is required by section 14.18.1 If a

saatsiz kaynak sunucu bu kurallara uyar ve proxy'ler ve istemciler, herhangi bir yanıt olmadan alınan herhangi bir yanıta kendi Tarihlerini ekler ([RFC 2068], bölüm 14.19'da belirtildiği gibi), önbellekler doğru şekilde çalışacaktır.

  - ETag and/or Content-Location, if the header would have been sent
    in a 200 response to the same request
  - Expires, Cache-Control, and/or Vary, if the field-value might
    differ from that sent in any previous response for the same
    variant If the conditional GET used a strong cache validator (see

Bölüm 13.3.3), yanıt diğer varlık başlıklarını İÇERMEMELİDİR. Aksi takdirde (yani koşullu GET zayıf bir doğrulayıcı kullandı), yanıt diğer varlık başlıklarını İÇERMEMELİDİR; bu, önbelleğe alınan varlık gövdeleri ile güncellenmiş başlıklar arasındaki tutarsızlıkları önler.

Bir 304 yanıtı, şu anda önbelleğe alınmamış bir varlığı gösteriyorsa, önbellek yanıtı göz ardı etmeli ve isteği koşulsuz olarak tekrar etmelidir * ZORUNLU *.

Bir önbellek, bir önbellek girişini güncellemek için alınan bir 304 yanıtı kullanıyorsa, önbellek, yanıtta verilen herhangi bir yeni alan değerini yansıtacak şekilde girişi güncelleştirmelidir * ZORUNLU *.

10.3.6 305 Proxy Kullan

İstenen kaynağa Konum alanı tarafından verilen proxy aracılığıyla ERİŞİLMELİDİR. Konum alanı, proxy'nin URI'sini verir. Alıcının bu tek isteği proxy aracılığıyla tekrar etmesi bekleniyor. 305 yanıt yalnızca kaynak sunucular tarafından oluşturulmalıdır * ZORUNLU *.

  Note: RFC 2068 was not clear that 305 was intended to redirect a
  single request, and to be generated by origin servers only.  Not
  observing these limitations has significant security consequences.

10.3.7 306 (Kullanılmamış)

306 durum kodu, spesifikasyonun önceki bir sürümünde kullanılmış, artık kullanılmamaktadır ve kod rezerve edilmiştir.

10.3.8 307 Geçici Yeniden Yönlendirme

İstenen kaynak geçici olarak farklı bir URI altında bulunuyor. Yeniden yönlendirme zaman zaman değiştirilebileceğinden, istemci gelecekteki istekler için İstek URI'sini kullanmaya devam ETMELİDİR. Bu yanıt, yalnızca Cache-Control veya Expires başlık alanıyla belirtilirse önbelleğe alınabilir.

Geçici URI'nin yanıttaki Konum alanı tarafından verilmesi GEREKİR. İstek yöntemi HEAD olmadıkça, yanıtın varlığı yeni URI (lar) a köprü içeren kısa bir hipermetin notu içermelidir, çünkü çoğu HTTP / 1.1 kullanıcı aracısı 307 durumunu anlamaz. Bu nedenle not, bir kullanıcının orijinal talebi yeni URI üzerinde tekrar etmesi için gerekli bilgileri içermelidir.

GET veya HEAD dışında bir isteğe yanıt olarak 307 durum kodu alınırsa, kullanıcı aracısı, talebin gönderildiği koşulları değiştirebileceğinden, kullanıcı tarafından onaylanmadıkça isteği otomatik olarak yeniden yönlendirmemelidir * ZORUNLU *.

Ben bulana kadar, şimdilik 302 kullanıyorum doğru cevabı.

Güncelleme ve sonuç:

HTTP 302, istemcilerle / tarayıcılarla en iyi uyumluluğa sahip olduğu bilindiğinden daha iyidir.


1
Kesinlikle kitap yolunun bir 401 ve yönlendirme olmadan bir giriş sayfası döndürmek olacağını söyleyebilirim, ancak seçeneklerinizin ne olduğundan emin değilim.
Nick Craver

1
@Nick iyi bir nokta, ancak klasik bir giriş sistemi oluşturuyor olsaydım bunun yan etkilerinden korkardım.
Pekka

1
@Pekka - Kesinlikle katılıyorum, bunun hangi platformda olduğuna bağlı olarak tüm bunların nasıl temiz bir şekilde idare edilebileceğine bağlı, ayrıca intranet vs internet devreye girse de inanıyorum ... genellikle bir intranette farklı bir şekilde kimlik doğrulaması yaparsınız, En azından benim deneyimimde.
Nick Craver

@Nick With 401 "Yanıt bir WWW-Authenticate başlık alanı İÇERMELİDİR" - Bunu bir MySQL veritabanıyla nasıl birleştirebilirim? AuthType Basic ve Digest, .htpassword vb. Gibi apache yapılandırma dosyalarıyla sınırlı değil mi?
Vidar Vestnes

Kullanıcı adı ve şifre isteyen temel tarayıcı iletişim kutusunu değil, özel bir giriş sayfası istiyorum ...
Vidar Vestnes

Yanıtlar:


66

Derdim 303 diğer bakın 302 Bulunan:

İstenen kaynak geçici olarak farklı bir URI altında bulunuyor. Yeniden yönlendirme zaman zaman değiştirilebileceğinden , istemcinin gelecekteki istekler için İstek-URI'sini kullanmaya devam etmesi GEREKİR. Bu yanıt, yalnızca Cache-Control veya Expires başlık alanıyla belirtilirse önbelleğe alınabilir.

bence bir giriş sayfasına en yakın şekilde uyuyor. Başlangıçta 303 see otherhangisinin işe yarayacağını düşündüm . Bazı düşünce sonra söyleyebilirim 302 Founddaha İstenen kaynak çünkü donanımdır edildi bulundu, sadece erişilebilir önce geçmesi başka bir sayfa var. Yanıt varsayılan olarak önbelleğe alınmaz, bu da iyidir.


4
Katılıyorum, ancak sanırım 302 Found, kaynağın başka bir url altında bulunduğunu gösteriyor. Ör. Mesajlarımı / sunucumu 302 ile yanıtlamak istiyorum çünkü "bugün" mesajlarım "/ login /" konumunda ("/ mesajlar /" yerine) ... 302 kullanıyorum ama hissetmiyorum bağlam% 100 eşleşiyor. Giriş sayfası farklı bir kaynak olduğundan ve istenen içeriğe sahip olmadığından.
Vidar Vestnes

2
@PHP_Jedi doğru. 303 bu açıdan daha uygun olabilir. Ancak, 302, istemci uyumluluğu açısından daha güvenilirdir.
Pekka

1
Evet, 303'ün "Talebe verilen yanıt farklı bir URI altında bulunabilir" şeklinde ifade ettiği için bağlama daha iyi uyabileceğini düşünüyorum. Bu bana başka bir URI'de bulunanın kaynağın kendisi olmadığını, sadece bu isteğe verilen yanıt olduğunu söylüyor.
Vidar Vestnes

3
@PHP_Jedi Buna bu kadar zaman ayırmaya değip değmeyeceğinden emin değilim. Http dünyasındaki hem istemciler hem de sunucular her halükarda son derece liberal ve hataya dayanıklı olmalıdır, bu nedenle kullanmanız 302veya daha iyi bilinmesi 303dışında gerçek bir fark olmayacaktır 302. Ayrıntı düzeyini övgüye değer buluyorum ve işleri doğru yapmak her zaman iyidir, ancak bu belirli alanda çok fazla çaba boşa gidebilir.
Pekka

28
Bilginize: Google 302'leri yayınladı
David Murdoch

51

Bu, HTTP yeniden yönlendirme mekanizmasının kötüye kullanılmasıdır. Kullanıcı yetkili değilse, uygulamanız geri dönmelidir 401 Unauthorized. Kullanıcının yetkilendirilmesi ancak istenen kaynağa erişimi 403 Forbiddenolmaması durumunda iade edilmelidir.

Yönlendirmeyi istemci tarafında, örneğin javascript ile yapmalısınız. yeniden yönlendirme için durum kodu çünkü gerekli yetkilendirme mevcut değil . Bunun için 30x kullanmak HTTP ile uyumlu değildir.

Mark Nottingham'dan HTTP Durum Kodları Hakkında Nasıl Düşünülür?

401 Yetkisiz, HTTP'nin istek kimlik doğrulama mekanizmasını tetikler.

401 Unauthorizeddurum kodu WWW-Authenticate, çeşitli kimlik doğrulama türlerini destekleyen bir başlığın bulunmasını gerektirir :

WWW-Authenticate: <type> bölge = <realm>

Taşıyıcı, OAuth, Temel, Özet, Çerez vb.


20
401, bazı durumlarda A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field( RFC ) olarak uygun olmayabilir ve tüm oturum açma sistemleri bu başlığı kullanmaz.
starbeamrainbowlabs

6
Korumalı bir sayfayı yenilediğinizi varsayalım; istemci tarafındaki javascript çağrılması için herhangi bir değişiklik olmayacak ve tarayıcı, kullanıcıyı giriş sayfasına yönlendirmek yerine bir giriş penceresi açacaktır - bu nedenle tek yol 30x kod kullanmaktır.
Claude Brisson

2
Golang, yönlendirme için 401'i kullanamaz. Bu, yönlendirmeler için 30 * kullanmamız gerektiği anlamına gelir.
EIMEI

4
@EIMEI muhakemenizi takiben, başka bir dil veya kütüphane sizi 401 kullanmaya zorladıysa, İnternet mahkum olur. Demek istediğim şu: Söyledikleriniz Golang'la ilgili bir soruna işaret ediyor (401'leri göndermeyi imkansız kılacak böyle bir tasarıma sahip olmasını şaşırtıcı bulsam da!)
Greg

2
@starbeamrainbowlabs WWW-Authenticate başlığında seçenek olarak Tanımlama Bilgisi tabanlı HTTP Kimlik Doğrulaması için bir taslak vardır. Bakınız: tools.ietf.org/html/draft-broyer-http-cookie-auth-00
aef

12

Bence uygun çözüm HTTP 401 (Yetkilendirilmemiş) başlığı.

http://en.wikipedia.org/wiki/HTTP_codes#4xx_Client_Error

Bu başlığın amacı tam olarak budur. Ancak, bir giriş sayfasına yeniden yönlendirmek yerine, doğru işlem şu şekilde olacaktır:

  • Kullanıcı oturum açmamış, oturum açma kısıtlı bir sayfaya erişmeyi deneyin.
  • sistem kullanıcının oturum açmadığını tanımlar
  • sistem HTTP 401 üstbilgisini döndürür VE oturum açma formunu aynı yanıtta görüntüler (yönlendirme değil).

Bu, site haritası bağlantıları içeren kullanışlı bir 404 sayfası ve örneğin bir arama formu sağlamak gibi iyi bir uygulamadır.

Görüşürüz.


20
RFC şunu belirtir: "Yanıt, istenen kaynak için geçerli bir sınama içeren bir WWW-Authenticate başlık alanı (bölüm 14.46) İÇERMELİDİR." Bir 401 yanıtı gerçekten yalnızca bir HTTP kimlik doğrulama şeması kullanıldığında uygulanabilir.
bshacklett

4
Bu durumda 403, erişimin sadece yasak olduğunu ve yetkilendirme başlığının yardımcı olmayacağını belirttiği için daha iyi olurdu
olanod

@bshacklett WWW-Authenticate, birçok kimlik doğrulama şemasıyla birlikte kullanılabilir (örn. Taşıyıcı, OAuth). Bkz developer.mozilla.org/en-US/docs/Web/HTTP/Headers/... ve iana.org/assignments/http-authschemes/http-authschemes.xhtml
filip26

WWW-Authenticate başlığında bir seçenek olarak Çerez tabanlı HTTP Kimlik Doğrulaması için bir taslak vardır. Bakınız: tools.ietf.org/html/draft-broyer-http-cookie-auth-00
aef
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.