2011-07-16 18 views
35

Al usar la autenticación http básica, el nombre de usuario se puede pasar en la URL, p.Escapar los caracteres de nombre de usuario en las URL de autenticación básica

http://[email protected]/path/ 

Pero ahora supongamos que el nombre de usuario es una dirección de correo electrónico, p. [email protected] Hacer esto es claramente ambiguo:

http://[email protected]@foo.com/path/ 

¿Hay alguna manera de escapar del carácter @ en el nombre de usuario? Probé la codificación URL estándar:

http://david%[email protected]/path/ 

Pero eso no lo hizo.

+0

No puede usar @ en las URL. ¿O te equivoqué? – Hnatt

+0

Sé que llegué un poco tarde a la fiesta, pero ¿simplemente te perdiste la parte de la contraseña? la sintaxis estándar debe ser 'http (s): // user: pass @ host'. Entonces, en su caso debería ser 'http (s): //david%40company.com: Y0ur% 24up3r% 243cur3P% 40% 24% 24w0rd @ foo.com'. – FatalMerlin

+0

@FatalMerlin puede tener el mismo sabor con solo nombre de usuario, y con nombre de usuario y contraseña. Aunque eso es, creo que es ortogonal al problema del escape. –

Respuesta

52

Según RFC 3986, sección 3.2.1, es necesario que haya codificado por ciento:

userinfo = *(unreserved/pct-encoded/sub-delims/":") 

por lo que parece

http://david%[email protected]/path/ 

es correcto. ¿Dónde estás tratando de leerlo? Tal vez necesita decodificar manualmente el valor?

+0

Tengo mi propio código del lado del servidor que procesa las credenciales. Necesito depurarlo y ver exactamente lo que recibo cuando escapo de esta manera. Voy a seguir! –

+2

Los clientes no parecen estar bien con esa sintaxis. p.ej. IE9 lo bloquea incluso antes de enviar cualquier solicitud, y muestra el error "Windows no puede encontrar 'http: //david%[email protected]/path/'. Verifique la ortografía y vuelva a intentarlo". Esto me lleva a creer que esta sintaxis en realidad no es compatible, a pesar de lo que pueda parecer del RFC. –

+0

Funciona bien usando curl ... –

Cuestiones relacionadas