RFC2617 говорит, что нужно кодировать имя пользователя и пароль в base64, но не говорит, какую кодировку символов использовать при создании октетов для ввода в алгоритм base64.
Должен ли я использовать US-ASCII или UTF8? Или кто-то уже где-то уладил этот вопрос?
Ответы:
RFC 2617 можно читать как «ISO-8859-1» или «undefined». Твой выбор. Известно, что многие серверы используют 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 pt. 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, pt. 3) - переопределить:
формат сообщений для ... текстовой информации заголовка в наборах символов, отличных от US-ASCII.
Но тогда RFC2616 (HTTP 1.1) определяет заголовок, используя правило TEXT, которое по умолчанию имеет значение iso-8859-1. Означает ли это, что каждое слово в этом заголовке должно быть закодированным словом (т.е.=?...?= формой)?
Также важно, что ни один текущий браузер этого не делает. Они используют utf-8 (Chrome, Opera), iso-8859-1 (Safari), системную кодовую страницу (IE) или что-то еще (например, только самый старший бит из utf-8 в случае Firefox).
Изменить: я только что понял, что этот ответ больше смотрит на проблему с точки зрения сервера.
РЛК в сторону, в Spring Framework , в BasicAuthenticationFilterклассе, по умолчанию UTF-8 .
Я считаю, что причиной этого выбора является то, что UTF-8 может кодировать все возможные символы, а ISO-8859-1 (или ASCII) - нет. Попытка использовать имя пользователя / пароль с символами, не поддерживаемыми в системе, может привести к нарушению поведения или (что еще хуже) к снижению безопасности.
Если вас интересует, что делают браузеры, когда вы вводите символы, отличные от ascii, в приглашении входа в систему, я просто попробовал с Firefox.
Кажется, что он лениво конвертирует все в ISO-8859-1, беря младший байт каждого значения Unicode, например:
User: 豚 (\u8c5a)
Password: 虎 (\u864e)
Кодируются так же, как:
User: Z (\u005a)
Password: N (\u004e)
0x5a 0x3a 0x4e base64-> WjpO