RFC2617 mówi, że należy zakodować nazwę użytkownika i hasło do base64, ale nie mówi, jakiego kodowania znaków użyć podczas tworzenia oktetów do wprowadzenia do algorytmu base64.
Czy powinienem założyć US-ASCII czy UTF8? A może ktoś już gdzieś rozstrzygnął tę kwestię?
Odpowiedzi:
RFC 2617 można odczytać jako „ISO-8859-1” lub „niezdefiniowany”. Twój wybór. Wiadomo, że wiele serwerów używa ISO-8859-1 (podoba lub nie) i zawiedzie, gdy wyślesz coś innego. Więc prawdopodobnie jedynym bezpiecznym wyborem jest trzymanie się ASCII.
Aby uzyskać więcej informacji i propozycję rozwiązania problemu, zobacz wersję roboczą „Parametr kodowania dla podstawowego uwierzytelniania HTTP” (który stanowił podstawę dla RFC 7617).
Od 2015 roku istnieje RFC 7617 , który zastępuje RFC 2617. W przeciwieństwie do starego RFC, nowy RFC wyraźnie definiuje kodowanie znaków, które mają być używane dla nazwy użytkownika i hasła.
charset="UTF-8"w swoim wezwaniu, na przykład: WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"Pełna wersja:
Przeczytaj specyfikację . Jeśli zawiera dodatkowe szczegóły, takie jak dokładna procedura kodowania i lista punktów kodowych Unicode, które powinny być obsługiwane.
Począwszy od 2018 r., Nowoczesne przeglądarki będą zwykle domyślnie używać UTF-8, jeśli użytkownik wprowadzi znaki inne niż ASCII jako nazwę użytkownika lub hasło (nawet jeśli serwer nie używa tego charsetparametru).
Sfera parametr nadal obsługuje tylko znaki ASCII nawet w dokumencie RFC 7617.
Krótka odpowiedź: iso-8859-1, chyba że zakodowane słowa są używane zgodnie z RFC2047 (MIME).
Dłuższe wyjaśnienie:
RFC2617, sekcja 2 (Uwierzytelnianie HTTP) definiuje podstawowe poświadczenia :
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
Specyfikacji nie należy czytać bez odwołania się do RFC2616 (HTTP 1.1) dla definicji w BNF (jak powyższa):
Ta specyfikacja jest uzupełnieniem specyfikacji HTTP / 1.1 2 . Używa rozszerzonej sekcji BNF 2.1 tego dokumentu i opiera się zarówno na nieterminalach zdefiniowanych w tym dokumencie, jak i na innych aspektach specyfikacji HTTP / 1.1.
RFC2616, sekcja 2.1 definiuje TEKST (moje wyróżnienie ):
Reguła TEKST jest używana tylko do opisowej zawartości pól i wartości, które nie mają być interpretowane przez parser komunikatów. Słowa * TEXT MOGĄ zawierać znaki z zestawów znaków innych niż ISO-8859-1 tylko wtedy, gdy są kodowane zgodnie z zasadami RFC 2047.
TEXT = <any OCTET except CTLs, but including LWS>
Jest to więc zdecydowanie iso-8859-1, chyba że wykryjesz inne kodowanie zgodne z regułami RFC2047 (MIME pkt 3):
// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=
W takim przypadku znak euro w słowie byłby zakodowany 0xA4zgodnie z ISO-8859-15 . Rozumiem, że należy sprawdzić te zakodowane ograniczniki słów, a następnie zdekodować zawarte w nich słowa w oparciu o określone kodowanie. Jeśli tego nie zrobisz, pomyślisz, że hasło to =?iso-8859-15?q?T¤ST?=(uwaga, 0xA4które zostanie zdekodowane, ¤gdy zostanie zinterpretowane jako iso-8859-1).
To jest moje rozumienie, nie mogę znaleźć bardziej wyraźnego potwierdzenia niż te RFC. A niektóre z nich wydają się sprzeczne. Na przykład jednym z 4 określonych celów RFC2047 (MIME, pkt 3) jest przedefiniowanie:
format wiadomości umożliwiający… tekstowe informacje w nagłówku w zestawach znaków innych niż US-ASCII.
Ale potem RFC2616 (HTTP 1.1) definiuje nagłówek przy użyciu reguły TEXT, która domyślnie jest ustawiona na iso-8859-1. Czy to oznacza, że każde słowo w tym nagłówku powinno być zakodowanym słowem (tj. =?...?=Formą)?
Co więcej, żadna obecna przeglądarka tego nie robi. Używają utf-8 (Chrome, Opera), iso-8859-1 (Safari), strony kodowej systemu (IE) lub czegoś innego (jak tylko najbardziej znaczący bit z utf-8 w przypadku Firefoksa).
Edycja: właśnie zdałem sobie sprawę, że ta odpowiedź przedstawia problem bardziej z perspektywy serwera.
RFC bok, w Spring Framework , w BasicAuthenticationFilterklasie, domyślnie jest UTF-8 .
Uważam, że powodem tego wyboru jest to, że UTF-8 jest w stanie zakodować wszystkie możliwe znaki, podczas gdy ISO-8859-1 (lub ASCII) nie. Próba użycia nazwy użytkownika / hasła ze znakami nieobsługiwanymi w systemie może prowadzić do nieprawidłowego zachowania lub (co gorsza) obniżenia bezpieczeństwa.
Jeśli jesteś zainteresowany tym, co robią przeglądarki, gdy wpisujesz znaki inne niż ASCII w monicie logowania, właśnie spróbowałem z Firefoksem.
Wydaje się, że leniwie konwertuje to wszystko na ISO-8859-1, pobierając najmniej znaczący bajt z każdej wartości Unicode, np .:
User: 豚 (\u8c5a)
Password: 虎 (\u864e)
Są zakodowane tak samo jak:
User: Z (\u005a)
Password: N (\u004e)
0x5a 0x3a 0x4e base64-> WjpO