He revisado muchas publicaciones y no he tenido éxito en la determinación de cómo deshacerme de la molesta d en la respuesta proveniente de mi servicio web de asmx, como en {"d": { "Respuesta": "OK", "Auth-Key": "JKPYZFZU"}}.json asmx y ese molesto d:
Esto está siendo creado por mi clase 'public UserDevice Dictionary' devolviendo el objeto Dictionary.
¡Sería muy feliz si la maldita cosa no lo pusiera todo en el objeto d!
Probablemente esté utilizando algún tipo de marco que automáticamente ajuste las respuestas de su servicio web json con el elemento d.
Sé que el serializador JSON de Microsoft agrega el d en el lado del servidor, y el código AJAX del lado del cliente que deserializa la cadena JSON espera que esté allí.
Creo que jQuery funciona de esta manera también.
se puede leer un poco más sobre esto en Rick Strahl's blog
y hay un camino para que regrese JSON pura (sin el elemento 'd') mediante el WCF "Raw" programming model.
Básicamente JSON notación de matriz ['hello'] válida JavaScript por sí solo mientras que la notación de objetos JSON {'d': ['hello'] } no es en sí misma JavaScript válido. Esto tiene la consecuencia de que la notación de matriz es ejecutable, lo que abre la posibilidad de ataques XSS. Envolver sus datos en un objeto por defecto ayuda a prevenir esto.
Puede leer más acerca de por qué está allí en un post by Dave Ward. (edición: como ha señalado @ user1334007, cromo etiquetas este sitio como inseguro ahora)
Un comentario por Dave Reed en ese artículo es particularmente informando:
Es una de esas características de seguridad que tiene una muy fácil de entender propósito. La protección no está realmente en contra de ejecutando accidentalmente la alerta en su ejemplo. Aunque ese es un beneficio de de 'd', aún tendrá que preocuparse por eso mientras evalúa el JSON para convertirlo en un objeto.
Lo que hace es evitar que la respuesta JSON sea al por mayor ejecutada como resultado de un ataque XSS. En dicho ataque, el atacante podría insertar un elemento de script que llame a un servicio web JSON, , incluso uno en un dominio diferente, ya que las etiquetas de script lo admiten. Y, ya que es una etiqueta de script después de todo, si la respuesta se parece a , javascript se ejecutará como javascript. El mismo ataque XSS puede sobrecargar el objeto o los constructores de la matriz (entre otras posibilidades) y así obtener acceso a los datos JSON del otro dominio.
Para tirar con éxito que fuera, que necesita (1) un sitio XSS vulnerables (good.com) - cualquier sitio va a hacer, (2) un servicio web JSON que devuelve una carga útil deseada en una petición GET (por ejemplo, el banco .com/getaccounts), (3) una ubicación malvada (evil.com) a la que enviar los datos que capturó de bank.com mientras la gente visita good.com, (4) un visitante desafortunado al good.com que acabo de estar registrado en el banco.com usando la misma sesión del navegador .
Proteger su servicio JSON de que devuelva javascript válido es solo una cosa que puede hacer para evitar esto. No permitir GET es otro (las etiquetas de script siempre tienen GET). Requerir un cierto encabezado HTTP es otro (las etiquetas de script no pueden establecer encabezados o valores personalizados). La pila de servicios web en ASP.NET AJAX hace todo esto. Cualquiera que cree su propia pila debe tener cuidado de hacer lo mismo.
¡Gracias por su respuesta oportuna! No sé por qué no encontré ese artículo. Lamentablemente me estoy comunicando con un dispositivo que no es un navegador, por lo que no es vulnerable a los ataques. Es una lástima que Microsoft no nos haya facilitado su solución 'útil'. –
Irónicamente, ese sitio ha sido etiquetado por Chrome como lleno de malware. – d512
PIA, pero tendré que seguir esta ruta. –
Me siento un poco estúpido al preguntar esto aquí, pero ¿qué significa 'PIA'? :) – gillyb
¡Dolor en el culo! A veces conocido como PITA. –