☰

¿Cómo pasar el signo de interrogación (?) en la contraseña para la autenticación básica HTTP en los parámetros de URL?

tag-icon • tag-icon .htaccess url encoding selenium
¿Cómo pasar el signo de interrogación (?) en la contraseña para la autenticación básica HTTP en los parámetros de URL?

Estoy automatizando un sitio web que requiere autenticación básica HTTP.

Las sugerencias dadas en este enlace funcionan a las mil maravillas en la mayoría de los casos:

¿Puede pasar usuario/contraseña para la autenticación básica HTTP en los parámetros de URL?

Sin embargo, algunos de los usuarios tienen un signo de interrogación ( ?) en la contraseña. Por favor indique cómo escapar del signo de interrogación.

PD: Soy consciente de que @en el nombre de usuario se puede escapar como %40.

Respuesta1

Supongo que te debes referir aInformación de usuarioparte de la URL en la que se pasan las credenciales de usuario, no "parámetros de URL" (que son parte de lacadena de consulta):

https://<userinfo>@example.com/foo?<query-string>

Al igual que con cualquier carácter que no esté permitido en ninguna parte de la URL (porque puede tener un significado especial), debe estar codificado en URL (codificado por ciento) %seguido del código hexadecimal de dos dígitos para ese carácter.

Entonces, @es %40y ?es %3F.

Pero esos no son los únicos dos caracteres que pueden necesitar codificación URL. Debería pasar el valor a través de una función de codificación de URL en su secuencia de comandos para codificar correctamente esa parte de la URL.

RFC 3986define qué caracteres están permitidos (sin codificar) en elInformación de usuarioparte de la URL:

userinfo    = *( unreserved / pct-encoded / sub-delims / ":" )
unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"

              / "*" / "+" / "," / ";" / "="

Por lo tanto, todo lo demás debe estar codificado en porcentaje, incluido :y %, si son parte delusuarioocontraseñapartes (para negar su significado especial).

También se indica en el mismo documento:

El uso del formato "usuario:contraseña" en el campo de información de usuario está obsoleto.

En consecuencia, el soporte del navegador ha sido irregular, yendo y viniendo según las versiones (la seguridad es una preocupación principal). Creo que las últimas versiones de Chrome (v79 probada) y Firefox admiten credenciales de usuario en la URL. He visto comentarios de que esto también funciona en la última versión de Safari(?), aunque no ha funcionado durante mucho tiempo y actualmente no me funciona (aunque no estoy ejecutando la última versión de iOS 12.4.1). ). YIE dejó de admitir nombres de usuario y contraseñas en la URLhace algunos años y no parece que vaya a volver.

información relacionada