{12} Comentarios.

1. 

   urko

   01Jul2011/

   Muy buen tutorial. Gracias
2. 

   yeikos

   01Jul2011/

   Cuidado, no todos los navegadores tienen soporte nativo del depurador console.

   • 

     Carlos Benítez

     01Jul2011/

     Si; es cierto: las versiones anteriores a IE8 no soportan ese comando.

     Sin embargo, en el artículo se ha utilizado únicamente con fines didácticos: doy por hecho que el público que consulte esta guía tiene el suficiente conocimiento Javascript como para entender el código sin mayor problema y que es capaz de modificarlo según sus necesidades. Es ‘norma de la casa’ llenar los códigos de ‘consoles’ para que nos indiquen en todo momento por dónde vamos 😉

     Gracias por el aviso!
3. 

   gnz/vnk

   01Jul2011/

   Hombre, siempre se ha sabido que no se debe usar JSONP con fuentes que no sean «de confianza», no?
4. 

   pedro

   01Jul2011/

   ¿Y usuando un lenguaje de servidor como paso intermedio? es decir, en vez de pedir directamten el json a http://itunes.apple.com/search?parametros ,haces una peticion ajax a , por ejemplo, itunes.php ( o lo que sea) y que sea este itunes.php quien pida el json y te lo devuelva a cliente.

   • 

     Carlos Benítez

     01Jul2011/

     Sería una solución interesante para tener un mínimo de control sobre el objeto devuelto. Le echaré un vistazo.
     Gracias!
5. 

   Raul

   04Jul2011/

   Buenas Carlos. Llevo unos dias leyendo tu blog y queria felicitarte por ello, interesante a la par que util.

   Respecto a lo que comentas en la entrada, dices que usando el metodo que obliga apple mediante la creacion de un script en el cuerpo del dom y recogiendo el resultado json mediante un callback, se compromete la seguridad de la pagina. Pero esto no ocurriria igual si obtuvieses los datos mediante una llamada ajax? En que se diferenciarian?
   Y cuando dices que se compromete la seguridad, te refieres al uso de eval en el resultado obtenido por apple, el cual puede disparar un js malintencionado?

   Gracias por adelantado.

   • 

     Carlos Benítez

     04Jul2011/

     Hola Raúl;
     cuando realizamos una llamada AJAX tradicional podemos manejar la respuesta del servidor antes de ejecutarla o evaluarla. Para entendernos, es como una entrada de usuario en un campo de un formulario: podemos limpiar y parsear aquello que el servidor nos envíe.

     Sin embargo, en este tipo otro tipo de llamadas, estas a las que nos referimos como JSONP, estamos permitiendo al código entrante ejecutarse a ciegas. Es decir, el servidor aquí no envía una respuesta que evaluamos y luego manipulamos, sino que se trata en realidad de una inyección de código que tenemos que asumir como fiable. Esto conlleva que, si por ejemplo tratáramos con un tercero malitencionado, éste pueda enviarnos scripts que se harían con el control total de la página: por esta vía, es relativamente fácil ‘capturar’ datos de usuario, monitorizar la actividad de la página, etc. Por eso no hace falta ni siquiera un eval para disparar ese tipo de código ya que el código devuelto puede ser autoejecutable.

     Lo preocupante de este tipo de peticiones a ciegas es que no tienen que enviarse siempre esos paquetes en cada petición, sino que pueden hacerlo de forma ocasional, siendo así casi indetectable por parte de los responsables. Pensemos en un tercero que solo envía ese código malintencionado cada 500 peticiones; o cuando sospecha que su API no está siendo usada correctamente, o cuando detecta que están entrando muchas peticiones desde el mismo server, etc…

     Como podemos ver, el uso de este tipo de servicios conlleva un riesgo de seguridad con el que tenemos que contar. Algo desde mi punto de vista innecesario ya que Apple podría simplemente ofrecer su API de un modo accesible a una petición normal AJAX igual que hace, por ejemplo, Twitter.

     Saludos.
6. 

   Raul

   06Jul2011/

   Muchas gracias por responder! Me has aclarado las dudas ^_^
7. 

   fcodiaz

   26Jul2011/

   Aaamm creo que estas mal entendiendo un poco las negras intenciones de Apple… :-/ yo no diría que Apple no acepta peticiones por XHR, ya que una de las limitantes del objeto XHR es que los recursos deben de estar en el mismo dominio:puerto desde donde son invocados al intentar hacer AJAX desde midominio.com.mx a http://itunes.apple.com/ no funcionará y no por que Apple no quiera o no acepte peticiones XHR si no porque esta es una limitante de seguridad de JavaScript.

   Lo que se tiene que hacer entonces son dos cosas en «AJAX» crossdomine… o hacer JSONP o hacer un proxy alojando en tu dominio. más bien lo que documentas y mencionas aquí son las desventajas de usar JSONP que no es más que incluir dinámicamente un js en nuestro sitio que invoque un callback que se le envía para evitar la restricción de dominio del XHR.

   El recurso termina siendo un API no-oficial por lo tanto una API no confiable ni segura y pudiese dar el caso de lo que mencionas

   Lo otro es hacer el proxy, crear un script PHP que consuma el dominio itunes.apple.com y nos imprima el resultado en un recurso dentro de nuestro dominio y así ya podemos hacer AJAX con XHR…
   Soy anti-Apple… pero creo que este post tacha de malo a Apple, muchas veces lo es… Pero en este caso no lo es… esta vez Apple es inocente

   • 

     Carlos Benítez

     26Jul2011/

     Si; es cierto el tema de los Ajax crossdomain. Sin embargo, hoy día no cuesta nada implementar este tipo de soluciones. El propio método AJAX de jQuery ya facilita el crossdomain para que no resulte complejo de interpretar.

     El uso de JSONP en si mismo tampoco conlleva demasiado problema ya que, por lo general, se puede implementar de forma que controlemos la entrada de datos que emite el servidor. Es por ejemplo lo que utilicé en el API de OpenLibra; sin embargo, Apple obliga a que inyectemos un código completamente a ciegas. Es con esa parte con la que no estoy de acuerdo: hay varias formas de ofrecer un API de un modo transparente al desarrollador y ésta no lo es.

     Gracias por tu aportación.
     Saludos!!
8. 

   fcodiaz

   26Jul2011/

   No sé cómo funciona exactamente la implementación de jQuery.getJSON, pero creo que el error va por parte de la implementación de jQuery.

   Porque según yo getJSON hace exactamente lo mismo que como remediaste tu problema, ya que según yo en peticiones remota se envía el callback igualado a “?” y jQuery le asigna un nombre aleatorio al callback que le enviaste a getJSON y antes de enviarse se remplaza el ultimo “?” por el nombre temporal del callback.

   Por lo que observe el problema se da cuando se pasan datos de envió; si se avía el callback:’?’ En el objeto de datos de envió no funciona correctamente por que “?” se pasa a su encode de URL por lo que la URL al final tiene un %3F y jQuery ya no remplaza el “?” por el nombre temporal del callback.
   No revise ni hice ingeniería en inversa, pero según yo si el segundo paramento se pasa un JSON; getJSON intenta hacer una petición por XHR por lo cual no se realiza al ver que es un dominio distinto esto lo observe en la consola de firebug en Console aparece la petición pero si se hace un JSONP no debería de aparecer en la concola por que aquí solo aparecen las peticiones XHR pero si aparece en la lista de recursos en la pestaña de Red.

   Y cuando se envía una sola url escrita “manualmente” o completa y el segundo parámetro es el callback no hay ningún problema el único problema es rederear las variables que se enviarían al servidor un paso que se supone getJSON haría por nosotros pero podemos usar jQuery.param para obtener esto, al final ponemos el callback igualado a nada, porque param() «encodea» y necesitamos que callback sea enviado como «?» y no su códec para que getJSON lo replace por el nombre del callback temporal

   Así es como pude solucionar usando jQuery.getJSON

   var url="http://itunes.apple.com/search?"+$.param(
   {
    'term'     : 'birds',
    'country'  : 'es',
    'entity'   : 'software',
    'limit'    : '1',
    'callback'  : ''
    }
   )+'?';
   console.log(url);
   $.getJSON(url,
   function( data ){
      console.log( "Search Result(s): " , data );
    }
   );
   

   Al final según yo realiza exactamente lo mismo que tú con:

   var urlToSend = 'http://itunes.apple.com/search?term=birds&country=es&entity=software&limit=1';
   urlToSend += '&callback=print_results'
   $('', {
     'src' : urlToSend
   }).appendTo('body');
   

   Y al intente realizar peticiones desde fuera a tu API y tengo exactamente las mismas situaciones, de hecho no pude acezar haciendo $.getJSON(url,{},callback), sería buena idea que implementarás el parámetro de callback para JSONP porque igual en tu dominio si funciona como si nada pero en externos tendríamos que crear nuestro proxy para poder consumir la API…

   PD: oye como le hago para que el codigo quede bonito en los comentarios? en algunos pos vi el codigo formateado….