online extension depurar debugger debug chrome breakpoint javascript google-chrome iframe same-origin-policy appjs

extension - javascript console chrome



Usar iframe con archivos locales en Chrome (3)

Me está costando trabajo averiguar cómo acceder a una página cargada en un iframe desde la página externa. Ambas páginas son archivos locales y estoy usando Chrome.

Tengo una página externa y muchas páginas interiores. La página externa siempre debe mostrar el título de la página interna (tiene sentido en mi aplicación, quizás menos en este ejemplo simplificado). Esto funciona sin ningún problema en AppJS, pero se me ha solicitado que haga que esta aplicación funcione directamente en el navegador. Me aparece el error " Bloqueado un marco con origen" nulo "para acceder a un marco con origen" nulo ". Los protocolos, dominios y puertos deben coincidir. ".

Creo que esto se debe a la misma política de origen de Chrome con respecto a los archivos locales, pero eso no me ayudó a solucionar el problema directamente. Puedo solucionar el problema en este ejemplo desglosado utilizando el método window.postMessage por Formas para eludir la política del mismo origen . Sin embargo, yendo más allá de este ejemplo, también quiero manipular el DOM de la página interna desde la página externa, ya que esto hará que mi código sea mucho más limpio, por lo que publicar mensajes no hará el trabajo.

Página externa

<!DOCTYPE html> <html> <head> <meta name="viewport"> </head> <body> This text is in the outer page <iframe src="html/Home.html" seamless id="PageContent_Iframe"></iframe> <script src="./js/LoadNewPage.js"></script> </body> </html>

Página interior

<!DOCTYPE html> <html> <head> <title id="Page_Title">Home</title> <meta name="viewport"> </head> <body> This text is in the inner page </body> </html>

JavaScript

var iFrameWindow = document.getElementById("PageContent_Iframe").contentWindow; var pageTitleElement = iFrameWindow.$("#Page_Title");

Per ¿Es probable que las versiones futuras de Chrome sean compatibles con contentWindow / contentDocument cuando iFrame carga un archivo html local desde un archivo html local? , Intenté lanzar Chrome con la bandera

--allow-file-access-from-files

Pero no hubo cambios en los resultados.

Por Deshabilitar la misma política de origen en Chrome , intenté ejecutar Chrome con la bandera

--disable-web-security

Pero nuevamente no hubo cambios en los resultados.

Per ¿Qué hace document.domain = document.domain do? , Tuve ambas páginas ejecutando el comando

document.domain = document.domain;

Esto dio como resultado el error " Bloqueado un marco con origen" nulo "de acceder a un marco con origen" nulo ". El marco que solicita acceso estableció" document.domain "en" ", pero el marco al que se accedió no lo hizo. Ambos deben establecerse" document.domain "al mismo valor para permitir el acceso " .

Por diversión, tenía ambas páginas ejecutando el comando

document.domain = "foo.com";

Esto produjo el error " Error no detectado: SecurityError: DOM Exception 18 ".

Estoy forcejeando. ¡Cualquier ayuda de personas más conocedoras sería fantástica! ¡Gracias!


Lamento decirte que he intentado durante semanas resolver este problema (lo necesitaba para un proyecto) y mi conclusión es que no es posible.

Hay muchos problemas con el acceso local a través de javascript con Chrome, y algunos de ellos pueden resolverse utilizando --allow-file-access-from-files y --disable-web-security , incluidas algunas características de HTML5 sin conexión, pero Definitivamente creo que no hay forma de acceder a los archivos locales.

Te recomiendo que no pierdas tu tiempo tratando de circunvenir esto y tratar de publicar mensajes que puedas interpretar en las páginas interiores, para que puedas hacer las modificaciones DOM allí.


Según nuestra discusión en mi cubo hace un minuto :)

Me topo con este mismo problema ( la respuesta de publicación de Ajax de js expresa sigue arrojando errores ) tratando de obtener una solicitud de publicación de AJAX para que funcione correctamente.

Lo que me ayudó no es ejecutar el archivo directamente desde el sistema de archivos sino ejecutarlo desde un servidor local. Usé el nodo para ejecutar express.js. Puede instalar express con el siguiente comando: npm install -g express

Una vez que se logra esto, puede crear un proyecto express con el siguiente comando: express -s -e expressTestApp

Ahora, en esa carpeta, debería ver un archivo llamado app.js y una carpeta llamada public. Coloque los archivos html con los que desea trabajar en la carpeta pública. Reemplacé el archivo app.js con el siguiente código:

var express = require(''/usr/lib/node_modules/express''); var app = express(); app.use(function(err, req, res, next){ console.error(err.stack); res.send(500, ''Something broke!''); }); app.use(express.bodyParser()); app.use(express.static(''public'')); app.listen(5555, function() { console.log("Server is up and running"); });

Tenga en cuenta que la línea requerida puede ser diferente. Tienes que encontrar donde tu sistema realmente expresa. Puede hacerlo con el siguiente comando: sudo find / -name express

Ahora, inicie el servidor web express con el siguiente comando: node app.js

En este momento, el servidor web está en funcionamiento. Continúe y abra una nave de navegación y navegue a su dirección IP (o si está en la misma máquina que su servidor, 127.0.0.1). Use la dirección IP: portnumber / filename.html donde el número de puerto es el 5555 en el archivo app.js que creamos.

Ahora en ese navegador, no debería (y no lo hizo cuando lo probamos) tener ninguno de estos mismos problemas.


file: // protocol y http: // protocol hacen que las cosas se comporten de forma muy diferente con respecto a iframes. Tuve los mismos problemas que describe con una aplicación en PhoneGap que usa el protocolo de archivos para acceder a todos los archivos locales dentro de la carpeta assets / www local.

Si parece que los navegadores modernos impiden la visualización de archivos "locales" usando el protocolo de archivos en iframes por razones de seguridad.

Terminamos tirando iframes y simplemente usando divs como "viewports". Afortunadamente, el tamaño total de nuestra aplicación no era tan grande, así que logramos cargar todo en una sola página.