Esto es extraño, me preguntaba si alguien podría arrojar algo de luz sobre por qué sucedió esto.La devolución de llamada JSONP no se ejecuta al ejecutar en localhost
Básicamente, me he estado jalando tratando de probar JSONP para poder implementar un servicio web JSON que otros sitios pueden usar. Estoy haciendo desarrollo en localhost, específicamente, Visual Studio 2008 y el servidor web integrado de Visual Studio 2008.
Así como una prueba de funcionamiento JSONP w/jQuery, que implementaron las siguientes:
$().ready(function() {
debugger;
try {
$.getJSON("<%= new Uri(Request.Url, "/").ToString() %>XssTest?callback=?", function(data) {
alert(data.abc);
});
} catch (err) {
alert(err);
}
});
Y en el servidor ..
<%= Request["callback"] %>({abc : 'def'})
Así que lo que termina pasando es que un punto de ruptura en el servidor y yo obtenemos el punto de interrupción tanto en el primer "depurador"; declaración en el script del lado del cliente, así como en el servidor. La URL JSONP se está invocando después de que se carga la página. Eso está funcionando bien.
El problema que estaba teniendo es que la devolución de llamada nunca se ejecutará. Probé esto tanto en IE8 como en Firefox 3.5. Ninguno de los dos invocaría la devolución de llamada. La captura (err) nunca fue alcanzada, tampoco. ¡No pasó nada!
que había quedado atrapado en esto durante una semana, e incluso probado con una petición HTTP con clave manualmente en Telnet en el puerto especificado para asegurarse de que el servidor está devolviendo el formato ...
callbackfn({abc : 'def'})
.. y es.
Entonces caí en la cuenta, lo que si cambio el nombre de host de localhost a localhost con un globalizador (''), es decir http://localhost.:41559/ en lugar de http://localhost:41559/ (sí, la adición de un punto a cualquier nombre de host es legal, es a DNS lo que global:: es para espacios de nombres C#). ¡Y luego funcionó! Internet Explorer y Firefox 3.5 finalmente me mostraron un mensaje de alerta cuando acabo de agregar un punto.
Así que esto me hace preguntarme, ¿qué está pasando aquí? ¿Por qué la generación de etiquetas finales de scripts funcionaría con un nombre de host de Internet y no con un localhost simple? ¿O es esa la pregunta correcta?
Claramente esto se implementa por razones de seguridad, pero ¿qué están tratando de asegurar? Y, al hacer que funcione con un punto, ¿acabo de exponer un agujero de seguridad en esta característica de seguridad?
Por cierto, el archivo de mi host, aunque está alterado para otros hosts, no tiene nada de especial con localhost; el predeterminado 127.0.0.1/:: 1 sigue en su lugar sin anulaciones a continuación.
SEGUIMIENTO: llegué más allá de esto para fines de desarrollo local mediante la adición:
127.0.0.1 local.mysite.com
.. a mi archivo de hosts, a continuación, añadir el siguiente código a mi global.asax:
protected void Application_BeginRequest(object sender, EventArgs e)
{
if (Request.Headers["Host"].Split(':')[0] == "localhost")
{
Response.Redirect(
Request.Url.Scheme
+ "://"
+ "local.mysite.com"
+ ":" + Request.Url.Port.ToString()
+ Request.Url.PathAndQuery
, true);
}
}
Sugiero usar herramientas como firebug y ver si la solicitud de "script" se está haciendo para las cosas JSONP, y realmente ver qué datos están volviendo. –
Los datos eran válidos. Como se describió, la solución fue alejarse de localhost (el script y los datos permanecían igual) y eso lo "solucionó", pero no explica completamente lo que está sucediendo. –
sí, es por eso que sugiero registrar los acontecimientos para la versión no fijada. –