RFC2617, kullanıcı adını ve parolayı base64 olarak kodlamayı söylüyor, ancak base64 algoritmasına giriş için sekizli oluştururken hangi karakter kodlamasının kullanılacağını söylemiyor.

US-ASCII veya UTF8 varsaymalı mıyım? Ya da birisi bu soruyu bir yerde çözdü mü?

Orijinal teknik özellik - RFC 2617

RFC 2617 , "ISO-8859-1" veya "tanımsız" olarak okunabilir. Senin seçimin. Pek çok sunucunun ISO-8859-1'i (beğenin ya da beğenmeyin) kullandığı ve başka bir şey gönderdiğinizde başarısız olacağı bilinmektedir. Yani muhtemelen tek güvenli seçenek ASCII'ye bağlı kalmaktır.

Daha fazla bilgi ve durumu düzeltme önerisi için, "HTTP Temel Kimlik Doğrulaması için Kodlama Parametresi" (RFC 7617'nin temelini oluşturan) taslağına bakın .

Yeni - RFC 7617

2015'ten beri , RFC 2617'yi geçersiz kılan RFC 7617 vardır. Eski RFC'nin aksine, yeni RFC, kullanıcı adı ve parola için kullanılacak karakter kodlamasını açıkça tanımlar.

• Varsayılan kodlama hala tanımsızdır. Yalnızca US-ASCII ile uyumlu olması gerekir (yani ASCII baytlarını, UTF-8'in yaptığı gibi ASCII baytlarla eşleştirir).
• Sunucu isteğe bağlı olarak aşağıdaki gibi ek bir kimlik doğrulama parametresi gönderebilir charset="UTF-8":
  WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"
  Bu, sunucunun kullanıcı adı / paroladaki ASCII olmayan karakterleri kabul edeceğini ve bunların UTF-8'de (özellikle Normalleştirme Formu C) kodlanmasını beklediğini duyurur. . Yalnızca UTF-8'e izin verildiğini unutmayın.

Tam sürüm:

Spesifikasyonu okuyun . Tam kodlama prosedürü ve desteklenmesi gereken Unicode kod noktalarının listesi gibi ek ayrıntılar içeriyorsa.

Tarayıcı desteği

2018 itibariyle, modern tarayıcılar, bir kullanıcı kullanıcı adı veya parola için ASCII olmayan karakterler girerse (sunucu charsetparametreyi kullanmasa bile) varsayılan olarak UTF-8'i kullanacaktır .

• Chrome ayrıca UTF-8 kullanıyor gibi görünüyor
• Internet Explorer UTF-8 kullanmıyor ( sorun # 11879588 )
• Firefox şu anda v59 için planlanan bir değişikliği deniyor ( hata 1419658 )

Diyar

Bölge parametresi hala sadece bile RFC 7617 ASCII karakterleri destekler.

Kısa cevap: iso-8859-1, kodlanmış kelimeler RFC2047 (MIME) ile uyumlu olarak kullanılmadığı sürece.

Daha uzun açıklama:

RFC2617, bölüm 2 (HTTP Kimlik Doğrulaması) temel kimlik bilgilerini tanımlar :

basic-credentials = base64-user-pass
base64-user-pass  = <base64 encoding of user-pass, 
                     except not limited to 76 char/line>
user-pass         = userid ":" password
userid            = *<TEXT excluding ":">
password          = *TEXT

Spesifikasyon, BNF'deki tanımlar için RFC2616'ya (HTTP 1.1) başvurulmadan okunmamalıdır (yukarıdaki gibi):

Bu belirtim, HTTP / 1.1 belirtimi 2 için bir tamamlayıcıdır . Bu belgenin artırılmış BNF bölümü 2.1'i kullanır ve hem o belgede tanımlanan uçbirim olmayanlara hem de HTTP / 1.1 belirtiminin diğer yönlerine dayanır.

RFC2616, bölüm 2.1 tanımlar METİN (vurgu benim):

METİN kuralı yalnızca açıklayıcı alan içerikleri ve mesaj ayrıştırıcısı tarafından yorumlanması amaçlanmayan değerler için kullanılır. * METİN kelimeleri, yalnızca RFC 2047 kurallarına göre kodlandığında , ISO-8859-1 dışındaki karakter kümelerinden karakterler içerebilir .

TEXT           = <any OCTET except CTLs, but including LWS>

Dolayısıyla, RFC2047 (MIME pt. 3) kurallarına göre başka bir kodlama tespit etmediğiniz sürece kesinlikle iso- 8859-1'dir :

// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=

Bu durumda kelimedeki euro işareti iso-8859-15'e0xA4 göre kodlanacaktır . Anladığım kadarıyla, bu kodlanmış kelime sınırlayıcıları kontrol etmeniz ve ardından belirtilen kodlamaya göre içindeki kelimelerin kodunu çözmeniz gerekir. Bunu yapmazsanız, parolanın olduğunu düşüneceksiniz =?iso-8859-15?q?T¤ST?=( iso-8859-1 olarak yorumlandığında 0xA4kodunun çözüleceğine dikkat edin ¤).

Anladığım kadarıyla bu RFC'lerden daha açık onay bulamıyorum. Ve bazıları çelişkili görünüyor. Örneğin, RFC2047'nin (MIME, pt. 3) belirtilen 4 hedefinden biri aşağıdakileri yeniden tanımlamaktır:

US-ASCII dışındaki karakter kümelerinde ... metin başlık bilgilerine izin verecek mesajların biçimi.

Ancak RFC2616 (HTTP 1.1), varsayılan olarak iso-8859-1 olan TEXT kuralını kullanarak bir başlık tanımlar. Bu, bu başlıktaki her kelimenin şifreli bir kelime (yani =?...?=form) olması gerektiği anlamına mı geliyor ?

Ayrıca geçerli olan hiçbir tarayıcı bunu yapmaz. Utf-8 (Chrome, Opera), iso-8859-1 (Safari), sistem kodu sayfası (IE) veya başka bir şey kullanıyorlar (Firefox durumunda sadece utf-8'deki en önemli bit gibi).

Düzenleme: Bu cevabın konuya daha çok sunucu tarafı perspektifinden baktığını yeni fark ettim.

RFC'lerde kenara, içinde Bahar çerçevesinde , BasicAuthenticationFiltersınıf, varsayılan UTF-8 .

Bu seçimin nedeni, UTF-8'in tüm olası karakterleri kodlayabildiğine, ISO-8859-1 (veya ASCII) ise kodlayamayacağına inanıyorum. Sistemde desteklenmeyen karakterlerle kullanıcı adı / şifre kullanmaya çalışmak, hatalı davranışa veya (belki daha kötüsü) güvenliğin azalmasına neden olabilir.

Giriş isteminde ascii olmayan karakterler girdiğinizde tarayıcıların ne yaptığını merak ediyorsanız, Firefox ile denedim.

Her unicode değerinin en önemsiz baytını alarak her şeyi tembel bir şekilde ISO-8859-1'e dönüştürüyor gibi görünüyor, örneğin:

User: 豚 (\u8c5a)
Password: 虎 (\u864e)

Aynı şekilde kodlanır:

User: Z (\u005a)
Password: N (\u004e)

0x5a 0x3a 0x4e base64-> WjpO