¿Se puede pasar usuario / paso para la autenticación básica HTTP en los parámetros de URL?

153

Creo que esto no es posible, pero alguien que conozco insistió en que funciona. Ni siquiera sé qué parámetros probar, y no he encontrado esto documentado en ninguna parte.

Intenté http://myserver.com/~user=username&password=mypassword pero no funciona.

¿Puede confirmar que de hecho no es posible pasar al usuario / pasar a través de parámetros HTTP (GET o POST)?

authentication http http-basic-authentication

— ripper234
fuente

99

usuario: pass@example.com

— Dedo

@sam, ¿qué? ¿Cómo se vería la URL completa?

— ripper234

44

Todo en la especificación ietf.org/rfc/rfc1738.txt (3.1)

— Mancha

@sam - Lo siento, no pude analizar tu comentario por alguna razón.

— ripper234

200

De hecho, no es posible pasar el nombre de usuario y la contraseña a través de parámetros de consulta en la autenticación HTTP estándar. En su lugar, utiliza un formato de URL especial, como este: http://username:password@example.com/- esto envía las credenciales en el encabezado estándar de "Autorización" HTTP.

Es posible que la persona con la que estaba hablando estuviera pensando en un módulo o código personalizado que examinara los parámetros de la consulta y verificara las credenciales. Sin embargo, esto no es una autenticación HTTP estándar, es algo específico de la aplicación.

— womble
fuente

1

Gracias, esto es justo lo que estaba buscando ... no es crítico que sean parámetros GET, solo que puedo crearlo en la URL.

— ripper234

42

Para su información, el http://username:password@example.comformato ya no es compatible con IE o Chrome , no se sorprendería si otros siguieran su ejemplo si aún no lo han hecho.

— TJ Crowder

11

En realidad funciona bien en Chrome. Solo IE está siendo un mocoso mimado.

— Damien Overeem ツ

1

@DamienOvereem, ¿en qué versión de Chrome estás? Estoy en Mac OS X 37 y no parece funcionar para mí

— Chris DaMour

11

Desde entonces supe que Chrome lo había deshabilitado por un tiempo, pero volví a habilitar esta función más tarde. También he aprendido que Safari arrojará errores de phishing cuando se encuentre con este tipo de enlaces. Básicamente, el tiempo de autenticación HTTP basada en URL ha terminado ...

— Damien Overeem ツ

18

No se recomiendan los parámetros básicos de autenticación en URL

Hay un campo de encabezado de autorización para este propósito, verifíquelo aquí: lista de encabezado http

Aquí se escribe cómo usarlo: autenticación de acceso básica

Allí también puede leer que, aunque todavía es compatible con algunos navegadores, no se recomienda la solución sugerida de agregar las credenciales de autorización básicas en la URL.

Lea también el capítulo 4.1 en RFC 2617 - Autenticación HTTP para obtener más detalles sobre por qué NO utilizar la autenticación básica.

Pasando parámetros de autenticación en la cadena de consulta

Al usar OAuth u otros servicios de autenticación, a menudo también puede enviar su token de acceso en una cadena de consulta en lugar de en un encabezado de autorización, así que algo como:

GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD

— Marchitar
fuente

¿Y cómo se codifica un encabezado de autorización en una URL?

— womble

2

¿No es ese el formulario que ha declarado ahora en desuso?

— womble

2

La pregunta que respondió con "Hay un campo de encabezado de autorización para este propósito" fue preguntar cómo colocar los parámetros de autenticación en la URL . Si no puede codificar los campos de encabezado HTTP en una URL (que no puede), su respuesta es no secuencial.

— womble

¿Puedes citar dónde en el estándar URI dice que pasar los parámetros básicos de autenticación en URI está en desuso? RFC 2396 solo dice que "NO SE RECOMIENDA" porque los detalles de autenticación en texto plano no son, en muchas circunstancias, una buena idea (de lo cual estoy de acuerdo), mientras que RFC 7235 no menciona nada. En ninguna parte de las especificaciones que puedo buscar dice que está en desuso.

— Lie Ryan

1

@Wilt: Tengo que disculparme, de hecho tienes razón. Su sugerencia de que la especificación fue "alterada" me instigó a investigar más a fondo (un RFC nunca se modifica una vez que se publica / numera). Acabo de descubrir que RFC 2396 ha sido reemplazado por RFC 3986 , que no pude encontrar antes. RFC 3986 menciona la depreciación del nombre de usuario: sintaxis de contraseña:Use of the format "user:password" in the userinfo field is deprecated.

— Lie Ryan

17

http: // username: password@example.com funcionará para Firefox, Chrome, Safari, PERO no para IE.

Microsoft Knowledge Base

— Kumar girish
fuente

2

Esta capacidad se eliminó de Chrome 19+. Ver code.google.com/p/chromium/issues/detail?id=123150

— Moshe Katz

44

Al leer ese informe de error, se volvió a agregar a Chrome 20. Ciertamente, esperaría ver muchas quejas continuas si no lo hubiera sido.

— womble

Ahora lo solicité para Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/… . Caso de uso ligeramente diferente, pero aborda el mismo problema;)

— SimonSimCity

@Diago si la contraseña contiene '@', entonces no funciona. da un error fatal, ¿alguien puede decirme cómo podemos dar nombre de usuario y contraseña a la vez?

— Ashish Jain

@AshishJain: intentaría escapar @de la contraseña como %40. (Sin embargo, no sé si eso funciona, y podría depender del servidor o la combinación de navegador / servidor).

— David Moles

0

Es (obviamente) posible enviar cualquier cadena en los parámetros GET, aunque no se recomienda enviar el nombre de usuario y la contraseña, ya que puede hacerlo altamente visible, especialmente si no está en una solicitud AJAX.

Sin embargo, deberá codificar la página del servidor para extraer el nombre de usuario y la contraseña y luego validarlos y usarlos de la manera que sea necesaria.

— Steve Smith
fuente