Consultas JSONP y entre dominios: cómo actualizar / manipular en lugar de solo leer

Question

Así que estoy leyendo The Art & amp; La ciencia de Javascript, que es un buen libro, y tiene una buena sección sobre JSONP. He estado leyendo todo lo que puedo sobre esto hoy, e incluso revisando cada pregunta aquí en StackOverflow. JSONP es una gran idea, pero solo parece resolver el " mismo problema de origen " para obtener datos, pero no se ocupa de cambiar datos.

¿Acabo de perderme todos los blogs que hablaron de esto o JSONP no es la solución que esperaba?

Answer 1

JSONP da como resultado que se genere una etiqueta SCRIPT a otro servidor con cualquier parámetro que pueda ser requerido como una solicitud GET. por ejemplo

<script src="http://myserver.com/getjson?customer=232&callback=jsonp543354" type="text/javascript">
</script>

Técnicamente no hay nada que detenga este tipo de solicitud al alterar los datos en el servidor, por ejemplo. especificando newName = Tony. Su respuesta podría ser si la actualización tuvo éxito o no. Usted estará limitado por lo que pueda caber en una cadena de consulta. Si va con este enfoque, agregue algún elemento aleatorio como parámetro para que el proxy no lo guarde en caché.

Algunas personas pueden considerar que esto va en contra de la forma en que se supone que funcionan los GET, es decir, no deberían hacer que los datos cambien.

Answer 2

Sí, y sinceramente me gustaría atenerme a ese paradigma. Sin embargo, podría doblar la regla y decir que, las solicitudes que no alteren / traten con los datos de CRUCIAL serán accesibles a través de llamadas GET ... hm ...

Por ejemplo, estoy creando un sistema de carrito de compras, y creo que permitir la adición / eliminación de / etc de artículos a / desde un carrito podría exponerse fácilmente a través de GET, ya que aunque puede cambiar los datos, no puede hacer cualquier cosa crítica con él. Si alguien añadiera maliciosamente 1.000 monitores de pantalla plana a su carrito de compras, habría al menos un paso de verificación que NO sería vulnerable a ningún ataque (una página ASP.NET estándar en ese momento, con verificación y todo ese jazz).

¿Es esta una solución buena / viable en la opinión de cualquiera?