Basta ya de buscar por todo internet ya que llegaste al espacio necesario, poseemos la solución que buscas pero sin complicarte.
Solución:
Aquí hay un método directo que siempre me ha funcionado:
var jq = document.createElement('script');
jq.src = "https://ajax.googleapis.com/ajax/libs/jquery/2.2.4/jquery.min.js";
document.getElementsByTagName('head')[0].appendChild(jq);
// ... give time for script to load, then type (or see below for non wait option)
jQuery.noConflict();
Simplemente pegue cada línea en la consola, una a la vez. (En realidad, funciona bien si selecciona las líneas y las pega en DevTools Console todo a la vez).
Es posible que vea inmediatamente un error: Uncaught ReferenceError: jQuery is not defined. Ignóralo: DevTools te está tomando el pelo. (El débil intento de humor de Google, tal vez…)
Luego, en la consola de DevTools, pruébalo:
$('div').length; //press Enter
Si obtiene un error, inténtelo de esta manera:
jQuery('div').length
Con suerte, el primero funcionará, pero a veces necesitará usar el segundo método.
Este código es gracias a jondavidjohn, de esta publicación original.
Utilice fragmentos.
- Copie el código jQuery y péguelo en un fragmento.
- Ejecute el Fragmento.
Desafortunadamente, ahora debido a lo que parece ser la moda más nueva en la prevención de “XSS” (secuencias de comandos entre sitios), esos complementos ya no funcionan. Puede haber un propósito noble detrás de estos cambios, y solo estoy tratando de entender QUÉ cambió. Creo que tiene algo que ver con la “política de seguridad de contenido”, de la que he oído hablar recientemente y de la que tengo muy poco conocimiento.
Si. La razón por la que estos complementos no funcionan es que no se pueden distinguir de los ataques MITM (man-in-the-middle) en los que los atacantes maliciosos pueden inyectar JavaScript arbitrario. CSP (Content-Security-Policy) está diseñado para evitar que esto suceda ejecutando solo JavaScript confiable desde una lista blanca de fuentes. Desafortunadamente, actualmente no hay una manera fácil de lidiar con esto en Chrome o Firefox hasta que la lista blanca de desarrolladores inyectó JavaScript/CSS de los autores del complemento. Es poco probable que esto suceda, ya que Chrome tiene una guía para desarrolladores de aplicaciones sobre cómo cumplir con la política de CSP.
Mientras tanto, le recomiendo que se ponga al día con los artículos de OWASP sobre XSS para que pueda aprender por qué es tan importante.
Enfoque no recomendado
Puede descargar el complemento “Desactivar política de seguridad de contenido” de la tienda de Chrome. Use esto solo para el desarrollo local. Tenga en cuenta que si hace esto, un ISP malicioso o un atacante dedicado aún pueden inyectar scripts en un ataque MITM (si tienen el control de su enrutador, por ejemplo).
Enfoque recomendado
No inyecte jQuery, pero póngalo en su página. Agregue una etiqueta de CSP:
Aquí pondrías algo como default-src 'self'; script-src https://cdn.com/jquery donde cdn.com es desde donde estás descargando jQuery. Vaya un paso más allá y agregue un hash de integridad de subrecursos. Si la CDN alguna vez se ve comprometida, se vuelve maliciosa o se convierte en MITM, el hash no coincidirá y el script malicioso no se cargará. Además, nunca puedes confiar realmente en los complementos por la misma razón.
Si decide no usar un CDN, puede usar un administrador de paquetes (como nodo o Bower) que descargará una versión específica de jQuery para usted. Luego simplemente cárguelo localmente. Por supuesto, para la producción, generalmente desea utilizar la CDN para que sus visitantes puedan descargar desde un centro de datos más cercano. Además, si está utilizando Cloudflare, es probable que hayan almacenado en caché esa versión específica de jQuery, por lo que no tienen que seguir descargándola.
Prototipos
Si su motivación es la creación de prototipos, existen soluciones alternativas:
No recomendado: puede raspar el sitio web, hacer sus modificaciones y luego presentarlo al cliente.
Recomendado: En lugar de hacer modificaciones en un sitio web en vivo, deberías hacer prototipos rápidos. Las ventajas de esto son:
-
Si está sentado con el cliente, el cliente puede ver exactamente lo que está haciendo.
-
Se trata de prototipos abstractos y no de detalles concretos, que deberían estar establecidos en el contrato. Visite ux.stackexchange.com para preguntas sobre pantallas de esqueleto.
-
Puede explicarle al cliente por qué no puede hacer X (inyectar jQuery en sitios en vivo) cuando debería estar haciendo Y (ver el resto de la respuesta), lo que con suerte los convencerá de adoptar una mejor practicas de seguridad
-
Los prototipos se pueden levantar y desechar rápidamente, e incluso puede conservar las revisiones para fines de comparación. Los cambios en un sitio en vivo no lo hacen fácil
Valoraciones y comentarios
Si aceptas, tienes la opción de dejar un ensayo acerca de qué te ha parecido esta noticia.