El RFC2617 dice codificar el nombre de usuario y la contraseña en base64, pero no dice qué codificación de caracteres usar al crear los octetos para la entrada en el algoritmo base64.
¿Debería asumir US-ASCII o UTF8? ¿O alguien ya ha resuelto esta cuestión en algún lugar?
Respuestas:
RFC 2617 se puede leer como "ISO-8859-1" o "indefinido". Tu elección. Se sabe que muchos servidores usan ISO-8859-1 (te guste o no) y fallarán cuando envíes algo más. Así que probablemente la única opción segura sea ceñirse a ASCII.
Para obtener más información y una propuesta para solucionar la situación, consulte el borrador "Un parámetro de codificación para la autenticación básica HTTP" (que formó la base de RFC 7617).
Desde 2015 existe el RFC 7617 , que deja obsoleto el RFC 2617. A diferencia del antiguo RFC, el nuevo RFC define explícitamente la codificación de caracteres que se utilizará para el nombre de usuario y la contraseña.
charset="UTF-8"en su desafío, como este: WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"Versión completa:
Lea la especificación . Si contiene detalles adicionales, como el procedimiento de codificación exacto y la lista de puntos de código Unicode que deben admitirse.
A partir de 2018, los navegadores modernos generalmente usarán UTF-8 de forma predeterminada si un usuario ingresa caracteres no ASCII para el nombre de usuario o la contraseña (incluso si el servidor no usa el charsetparámetro).
El parámetro de reino todavía solo admite caracteres ASCII incluso en RFC 7617.
Respuesta corta: iso-8859-1 a menos que se utilicen palabras codificadas de acuerdo con RFC2047 (MIME).
Explicación más larga:
RFC2617, sección 2 (Autenticación HTTP) define las credenciales básicas :
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
La especificación no debe leerse sin consultar RFC2616 (HTTP 1.1) para obtener definiciones en BNF (como la anterior):
Esta especificación es un complemento de la especificación HTTP / 1.1 2 . Utiliza la sección 2.1 de BNF aumentada de ese documento y se basa tanto en los no terminales definidos en ese documento como en otros aspectos de la especificación HTTP / 1.1.
RFC2616, sección 2.1 define TEXTO (énfasis mío):
La regla TEXT solo se utiliza para valores y contenidos de campos descriptivos que no están destinados a ser interpretados por el analizador de mensajes. Las palabras * TEXT PUEDEN contener caracteres de conjuntos de caracteres distintos de ISO-8859-1 solo cuando se codifican de acuerdo con las reglas de RFC 2047.
TEXT = <any OCTET except CTLs, but including LWS>
Entonces, definitivamente es iso-8859-1 a menos que detecte alguna otra codificación de acuerdo con las reglas RFC2047 (MIME pt. 3):
// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=
En este caso, el signo del euro en la palabra se codificaría 0xA4según iso-8859-15 . Tengo entendido que debe verificar estos delimitadores de palabras codificadas y luego decodificar las palabras internas según la codificación especificada. Si no lo hace, pensará que la contraseña es =?iso-8859-15?q?T¤ST?=(observe que 0xA4se decodificará ¤cuando se interprete como iso-8859-1).
Este es mi entendimiento, no puedo encontrar una confirmación más explícita que estas RFC. Y algo de eso parece contradictorio. Por ejemplo, uno de los 4 objetivos declarados de RFC2047 (MIME, punto 3) es redefinir:
el formato de los mensajes para permitir ... información de encabezado textual en juegos de caracteres que no sean US-ASCII.
Pero luego RFC2616 (HTTP 1.1) define un encabezado usando la regla TEXT que por defecto es iso-8859-1. ¿Significa eso que cada palabra en este encabezado debe ser una palabra codificada (es decir, la =?...?=forma)?
También es relevante, ningún navegador actual hace esto. Usan utf-8 (Chrome, Opera), iso-8859-1 (Safari), la página de códigos del sistema (IE) o algo más (como solo el bit más significativo de utf-8 en el caso de Firefox).
Editar: Me acabo de dar cuenta de que esta respuesta analiza el problema más desde la perspectiva del lado del servidor.
Dejando a un lado las RFC, en Spring Framework , la BasicAuthenticationFilterclase, el valor predeterminado es UTF-8 .
Creo que la razón de esta elección es que UTF-8 es capaz de codificar todos los caracteres posibles, mientras que ISO-8859-1 (o ASCII) no lo es. Intentar utilizar un nombre de usuario / contraseña con caracteres no admitidos en el sistema puede provocar un comportamiento defectuoso o (quizás peor) una seguridad degradada.
Si está interesado en lo que hacen los navegadores cuando ingresa caracteres no ascii en el indicador de inicio de sesión, acabo de probar con Firefox.
Parece convertir perezosamente todo a ISO-8859-1 tomando el byte menos significativo de cada valor Unicode, por ejemplo:
User: 豚 (\u8c5a)
Password: 虎 (\u864e)
Están codificados de la misma manera que:
User: Z (\u005a)
Password: N (\u004e)
0x5a 0x3a 0x4e base64-> WjpO