RFC2617 говорить про кодування імені користувача та пароля до base64, але не говорить, яке кодування символів використовувати при створенні октетів для введення в алгоритм base64.
Чи слід приймати US-ASCII або UTF8? Або хтось уже десь вирішив це питання?
Відповіді:
RFC 2617 можна прочитати як "ISO-8859-1" або "невизначений". Твій вибір. Відомо, що багато серверів використовують ISO-8859-1 (подобається це вам чи ні) і не спрацюють, коли ви надішлете щось інше. Тож, мабуть, єдиний безпечний вибір - дотримуватися ASCII.
Для отримання додаткової інформації та пропозиції щодо виправлення ситуації див. Проект "Параметр кодування для базової автентифікації HTTP" (який склав основу для RFC 7617).
З 2015 року існує RFC 7617 , який застаріває RFC 2617. На відміну від старого RFC, новий RFC чітко визначає кодування символів, яке використовуватиметься для імені користувача та пароля.
charset="UTF-8"у своєму завданні, наприклад: WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"Повна версія:
Прочитайте специфікацію . Якщо містить додаткові деталі, такі як точна процедура кодування та список кодових точок Unicode, які слід підтримувати.
Починаючи з 2018 року, сучасні браузери, як правило, за замовчуванням використовують UTF-8, якщо користувач вводить символи, що не належать до ASCII, для імені користувача чи пароля (навіть якщо сервер не використовує charsetпараметр).
Параметр області все ще підтримує лише символи ASCII, навіть у RFC 7617.
Коротка відповідь: iso-8859-1, якщо кодовані слова не використовуються відповідно до RFC2047 (MIME).
Більш довге пояснення:
RFC2617, розділ 2 (Аутентифікація HTTP) визначає базові облікові дані :
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
Специфікацію не слід читати без посилання на RFC2616 (HTTP 1.1) для визначень у BNF (як і вище):
Ця специфікація є супутником специфікації HTTP / 1.1 2 . Він використовує розширений розділ 2.1 BNF цього документа і спирається як на нетермінали, визначені в цьому документі, так і на інші аспекти специфікації HTTP / 1.1.
RFC2616, розділ 2.1 визначає ТЕКСТ (наголос мій):
Правило TEXT використовується лише для описового вмісту поля та значень, які не призначені для інтерпретації аналізатором повідомлень. Слова * TEXT МОЖУТЬ містити символи з наборів символів, відмінних від ISO-8859-1, лише у випадку кодування згідно з правилами RFC 2047.
TEXT = <any OCTET except CTLs, but including LWS>
Тож це точно iso-8859-1, якщо ви не виявите якесь інше кодування згідно з правилами RFC2047 (MIME, п. 3):
// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=
У цьому випадку знак євро в цьому слові буде закодований 0xA4відповідно до ISO-8859-15 . Я розумію, що вам слід перевірити наявність цих закодованих роздільників слів, а потім декодувати слова всередині на основі вказаного кодування. Якщо ви цього не зробите, ви думаєте, що це пароль =?iso-8859-15?q?T¤ST?=(зауважте, що 0xA4він буде розшифрований ¤при інтерпретації як iso-8859-1).
Це моє розуміння, я не можу знайти більш явного підтвердження, ніж ці RFC. І дещо здається суперечливим. Наприклад, однією з 4 заявлених цілей RFC2047 (MIME, п. 3) є перевизначення:
формат повідомлень, що дозволяє ... інформацію про текстовий заголовок у наборах символів, відмінних від US-ASCII.
Але тоді RFC2616 (HTTP 1.1) визначає заголовок, використовуючи правило TEXT, яке за замовчуванням має значення iso-8859-1. Чи означає це, що кожне слово в цьому заголовку має бути закодованим словом (тобто =?...?=формою)?
Також актуально, жоден поточний браузер цього не робить. Вони використовують utf-8 (Chrome, Opera), iso-8859-1 (Safari), системну кодову сторінку (IE) або щось інше (як лише найважливіший біт із utf-8 у випадку з Firefox).
Редагувати: Я щойно зрозумів, що ця відповідь розглядає проблему більше з точки зору сервера.
За винятком RFC, у Spring , BasicAuthenticationFilterкласі, за замовчуванням UTF-8 .
Причиною такого вибору, я вважаю, є те, що UTF-8 здатний кодувати всі можливі символи, тоді як ISO-8859-1 (або ASCII) - ні. Спроба використовувати ім’я користувача / пароль із символами, які не підтримуються в системі, може призвести до порушення поведінки або (може гірше) до погіршення безпеки.
Якщо вас цікавить, що роблять браузери, коли ви вводите символи, що не є ascii, у рядку входу, я щойно спробував із Firefox.
Здається, ліниво перетворює everithing на ISO-8859-1, беручи найменш значущий байт кожного значення Unicode, наприклад:
User: 豚 (\u8c5a)
Password: 虎 (\u864e)
Кодуються так само, як:
User: Z (\u005a)
Password: N (\u004e)
0x5a 0x3a 0x4e base64-> WjpO