You are here

Mozilla Hispano

Utilizando dispositivos 2FA con la API WebAuthn

Noticias de Mozilla Hispano - Dom, 13/05/2018 - 20:34

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Emmanuel Sanchez.

Para proveer una seguridad mayor al momento de iniciar sesiones, los sitios web utilizan la autenticación de dos pasos (2FA, two-factor authentication), comúnmente utilizando una aplicación de smartphone o mensajes de texto. Estos mecanismos hacen que los usuarios sean menos susceptibles a los ataques de phishing, pero no son perfectos (los usuarios pueden ser engañados para que entreguen sus códigos y los mensajes de texto pueden ser interceptados de varias maneras).

Firefox 60 llegará con la API WebAuthn activada por defecto, proporcionando autenticación de dos factores basada en criptografía pública inmune al phishing como lo conocemos el día de hoy. A continuación daremos una introducción para aprender la forma de proteger a millones de usuarios que ya poseen dispositivos USB U2F FIDO.

Creando una nueva credencial

Empecemos con un ejemplo simple: vamos a requerir credenciales compatibles con el estándar de dispositivos USB FIDO U2F; existen muchos dispositivos compatibles con nombre como Yubikey, U2F Zero, y otros:

const cose_alg_ECDSA_w_SHA256 = -7; /* El reto debe de iniciarse en el servidor */ let challenge = new Uint8Array([21,31,105 /* 29 bytes más de números aleatorios generados por el servidor */]); let pubKeyCredParams = [{ type: "public-key", alg: cose_alg_ECDSA_w_SHA256 }]; let rp = { name: "Test Website" }; let user = { name: "Firefox User <firefox @example.com>", displayName: "Firefox User", id: new TextEncoder("utf-8").encode("firefox@example.com") }; let publicKey = {challenge, pubKeyCredParams, rp, user}; navigator.credentials.create({publicKey}) .then(decodeCredential);

En el caso de dispositivos U2F USB, esto hace que todos los dispositivos conectados esperen a algún tipo de interacción por parte del usuario. Tan pronto como el usuario toca el dispositivo este genera una nueva credencial y la promesa (Promise) se resuelve.

El función decodeCredential() descifrará la respuesta para recibir una referencia a una llave, ya sea  una referencia un par de llaves ECDSA almacenadas en el dispositivo, o las mismas llaves ECDSA cifradas con una llave del dispositivo secreta. La llave pública se envía sin cifrar.

La referencia de la llave, la llave pública, y la firma deben de ser verificadas por el servidor utilizando un reto generado al azar. Debido a que la información está relacionada criptográficamente con el servidor, la verificación fallará si el servidor origen no coincide. Esto evita que se utilicen credenciales de otros sitios web.

La referencia de la llave y la llave pública ahora estarán asociadas al usuario actual. La api WebAuthn no exige algún tipo de interfaz en el navegador, por lo que es responsabilidad del sitio web indicarle al usuario el momento en el que debe de conectar y registrar su dispositivo.

Obtener evidencia de una credencial ya existente

La siguiente ocasión que un usuario trate de autenticarse en un sitio web, este le solicitará que pruebe que aún posee el “segundo factor” que se creó en la sección anterior. El backend obtendrá la referencia de la llave y le enviará un nuevo desafío al usuario. Debido a que allowCredentials es un array, permite el envío de más de un token, en caso de un usuario tenga varios tokens (dispositivos) registrados en la misma cuenta.

/* El reto debe de realizarse en el servidor */ let challenge = new Uint8Array([42,42,33 /* 29 bytes más de números aleatorios generados por el servidor */]); let key = new Uint8Array(/* … obtener referencia de llave … */); let allowCredentials = [{ type: "public-key", id: key, transports: ["usb"] }]; let publicKey = {challenge, allowCredentials}; navigator.credentials.get({publicKey}) .then(decodeAssertion);

De nuevo, todos los dispositivos USB U2F van a esperar alguna interacción por parte del usuario. Cuanto el usuario toca un token este va a tratar de encontrar la llave que se encuentra en el dispositivo a través de su referencia, o tratará de desencriptarla en base a su llave secreta. En caso exitoso, entregará una firma. Sino, la autenticación fallará y se deberá de iniciar de nuevo el proceso para ingresar al sitio.

Después de decodificar, la firma y la llave son enviados al servidor. Si la clave almacenada con el manejador de llaves es capaz de resolver el desafío, se considera que fue exitoso y se le permite al usuario ingresar.

Autenticación de primer factor

La especificación Web Authentication también contiene mecanismos para poder autenticar a usuarios sin utilizar un usuario o una contraseña, solo un dispositivo seguro, como un entorno de ejecución seguro dentro de tu smartphone. En este modo, tu dispositivo no solo verifica que tienes posesión de él, sino que además lo desbloqueaste cib una contraseña (algo que tú conoces) y/o seguridad biométrica (algo que tú eres).

Esto le permitirá a los sitios web verificar tu identidad a su web desde tu computadora respondiendo a un mensaje que te aparecería en tu smartphone.

Los dispositivos FIDO U2F aún no son tan avanzados para permitir que esto ocurra, pero la siguiente generación sí lo será y los desarrolladores web podrán interactuar con esos dispositivos FIDO 2.0 usando Web Authentication.

WebAuthn, disponible en tu Firefox más cercano

Ésta fue una introducción muy pequeña al mundo de la autenticación Web e intencionalmente ignora muchos detalles como lo son la codificación CBOR y los formatos COSE_KEY, así como los parámetros que pueden ser utilizados para las funciones .create() y .get().

Nos gustaría fomentar que los desarrolladores empiecen a experimentar con WebAuthn, y permitirle a sus usuarios proteger sus sesiones con autenticaciones de dos factores tan pronto como estén disponibles. Al momento de escribir esto no conocemos bibliotecas para la utilización de WebAuthn-U2F, pero esperamos que estén disponilbes pronto. Si tú llegas a ver algo prometedor no dudes en avisarnos por los comentarios.

Es muy emocionate traer la estandarización de la autenticación de dos factores a la web; la criptografía de llave pública también protege nuestra información cuando viaja a través de internet a través del protocolo TLS, y ahora permite que los ataques phishing sean más difíciles de realizar. Prueba WebAuthn en Firefox (firefox.com).

Una nota final sobre pruebas

La autenticación Web es una poderosa característica. eso implica que solo puede ser utilizada en entornos seguros del navegador, y solo puede ser utilizado cuando el documento original tenga el mismo origen. Esto significa que puedes encontrar errores de seguridad cuando experimentes utilizando sitios web de pruebas (como jsfiddle.net).

Categorías: Mozilla Hispano

FLISoL Bogotá 2018: innovación social, cultura libre y software libre

Noticias de Mozilla Hispano - Mié, 09/05/2018 - 16:47

 

El pasado 28 de abril celebramos de la mejor manera el Festival Latinoamericano de instalación de Software libre en Bogotá.

 

Flisol Bogotá. Imagen en En TIC confío@EnTICconfio Apr 28 de 2018. “Hoy estamos en @flisol_bogota, festival de instalación de software libre más grande del mundo con más de 70 actividades durante todo el día. ¡No te lo pierdas! Inscripciones GRATIS en https://flisolbogota.org“.

 

 

En esta ocasión el festival permitió observar que la cultura libre, más allá de ser un espacio para la instalación de distribuciones de software, sistemas operativos o programas que promueven la apertura de Internet y el empoderamiento de las personas respecto a la tecnología, es una forma de contribuir y construir sociedades.

Flisol Bogotá. pb‏ @dicepb Apr 28 Retweeted #FlisolBogota (@flisol_bogota): #FlisolBogota y todas las salas llenas!

 

Asistieron más de 1600 personas las que participaron en más de 90 actividades en las que se incluían charlas, talleres, paneles, espacios para niños -FLISoL Kids-, un cinema de cultura libre, música, origami y mucho más.

 

Cinema Libre. Foto de: Viviana‏ @lviviana13 Apr 28. @GrupoLinuxUD presente con #CineLibre #FlisolBogotá

 

Flisol Bogotá. Foto de: RuБén AvilaH‏ @rubenavilah Apr 28

Así luce hoy #Flisol2018 Bogotá todos en la gran apertura de este evento. @flisol_bogota @FabaBogota

Mozilla Colombia dirigió de dos actividades: el testeo de Nightly y la creación de extensiones para Firefox. Las dos actividades estaban orientadas a personas con conocimientos avanzados en las herramientas y tecnologías de Mozilla, sin embargo, dada la diversidad de público, al final los talleres permitieron incluir a personas que no conocían Firefox, usuarios de Firefox y también desarrolladores y personas con conocimientos avanzados.

 

Taller Nightly. Foto de Gutemonik

 

Durante nuestro taller de testeo de Nightly instalamos la versión con fines de prueba preliminar a Firefox. Vimos las diferencias entre Nightly y Firefox, hicimos pruebas y también presentamos fallas. En esta actividad no solo hicimos revisiones desde la versión de escritorio, sino que tuvimos muchas instalaciones y ejercicios de testeo desde los celulares. Para las personas que tenían conocimientos avanzados, revisamos el Bug Tracker de Mozilla, el Blog de Firefox Nightly y también la documentación en Mozilla Developer Network. Este taller estuvo a cargo de los Mozillians Camilo Baquero y Kevín Díaz.

 

Participantes del taller Nightly. Foto de Gutemonik

 

De igual forma tuvimos el taller para crear extensiones Web para Firefox -y que también pueden ser compatibles con otros navegadores-. Hablamos y exploramos Firefox y el directorio de extensiones, de igual forma exploramos las API de WebExtensions. En seguida a través de un ejercicio práctica creamos nuestra primer extensión para Firefox. Para el público avanzado realizamos una exploración más profunda introduciéndonos en la anatomía y publicación de extensiones, además de revisar algo de RUST y dar una introducción para empezar a contribuir e involucrarse con la comunidad Mozilla. En este taller participó Alejandro Cortazar, representante del Grupo GLUD y Mónica Bonilla, Rep de Mozilla en Colombia.

 

Imagen tomada del perfil de Twitter de una participante del taller (@ingdalvarez)

 

Al final, tuvimos un grupo de personas que están interesadas en contribuir con los proyectos de Mozilla y con las que haremos versiones más avanzadas de las actividades desarrolladas durante el FLISoL. Entre estas personas están las chicas de Geek Girls Latam con quienes próximamente tendremos actividades y talleres bajo el marco de WoMoz.

 

Foto tomada del perfil de una Geek Girl Colombia (@Cangreja533)

 

¡Gracias a los organizadores, patrocinadores y todas las personas que estuvieron detrás de la organización del FLISoL Bogotá, 2018! Definitivamente es el evento de difusión de Software Libre más grande del mundo. ¿Quieres participar con una actividad, charla o taller para mostrar los proyectos y desarrollos de Mozilla el próximo año? ¡Ponte en contacto con algunos de los Mozillians en Colombia!

Categorías: Mozilla Hispano

Construyendo el DOM más rápido: análisis especulativo, asincrónico, diferido y precargado

Noticias de Mozilla Hispano - Mié, 11/04/2018 - 21:04

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

En 2017, la caja de herramientas para asegurar que tu página web cargue rápido incluye todo desde minificación y optimización de recursos hasta cacheo, uso de CDN, división de código y tree shaking (o eliminación de código muerto). Sin embargo, puedes obtener un gran aumento de rendimiento con solo unas pocas palabras clave y una estructuración cuidadosa de código, incluso si no aún no estás familiarizado con los conceptos mencionados anteriormente y no sabes cómo empezar.

El reciente estándar web <link rel="preload">, que te permite cargar recursos críticos de manera rápida, ya llegó a Firefox, lo que es una gran oportunidad para revisar algunos fundamentos y sumergirse en el desempeño asociado con analizar el DOM.

Comprender lo que pasa dentro de un navegador es la herramienta más poderosa para todos los desarrolladores web. Veremos cómo los navegadores interpretan tu código y cómo te ayudan a cargar las páginas más rápido con el análisis especulativo. Vamos a desglosar cómo funcionan defer y async, y cómo aprovechar la nueva palabra clave preload.

Bloques de construcción

HTML describe la estructura de una página web. Para darle sentido al HTML, los navegadores primero tienen que convertirlo en un formato que entiendan – el Modelo de Objeto del Documento, o DOM. El motor del navegador tiene una pieza especial de código llamada analizador que es usada para convertir datos de un formato a otro. Un analizador HTML convierte datos de HTML a DOM.

En HTML, la anidación define las relaciones padre-hijo entre las etiquetas. En el DOM, los objetos están enlazados en una estructura de datos de árbol capturando esas relaciones. Cada etiqueta HTML es representada por un nodo del árbol (un nodo DOM).

El navegador construye el DOM parte por parte. Tan pronto como lleguen los primeros trozos de código, éste empieza a analizar el HTML, agregando nodos a la estructura de árbol.

El DOM tiene dos roles: es la representación de objeto del documento HTML, y actúa como una interfaz conectando la página al mundo exterior, como JavaScript. Cuando llamas a document.getElementById(), el elemento que es retornado es un nodo DOM. Cada nodo DOM tiene muchas funciones que puedes usar para acceder a él y cambiarlo, y como consecuencia el usuario ve los cambios.

Los estilos CSS encontrados en una página web son mapeados dentro del CSSOM – el Modelo de Objeto de CSS. Es muy parecido al DOM, pero para el CSS en lugar del HTML. A diferencia del DOM, éste no puede ser construido incrementalmente. Ya que las reglas CSS pueden sobrescribirse unas con otras, el motor del navegador tiene que hacer cálculos complejos para determinar cómo aplicar el código CSS al DOM.

La historia de la etiqueta <script>

A medida que el navegador construye el DOM, si aparece una etiqueta <script>...</script> en el HTML, debe ejecutarla de inmediato. Si el script es externo, descarga el script primero.

En los viejos tiempos, para ejecutar un script, el análisis tenía que ser pausado. Se iniciaría de nuevo solo después que el motor de JavaScript ejecutara el código del script.

¿Por qué el análisis tiene que detenerse? Bueno, los scripts pueden cambiar tanto el HTML y su producto – el DOM. Los scripts pueden cambiar la estructura del DOM agregando nodos con document.createElement(). Para cambiar el HTML, los scripts pueden agregar contenido con la célebre función document.write(). Es célebre porque puede cambiar el HTML de formas que puede afectar aún más el análisis. Por ejemplo, la función puede insertar la apertura de una etiqueta de comentario que haga inválido todo el resto de HTML.

Los scripts también pueden consultar algo del DOM, y si esto pasa mientras el DOM todavía está siendo construido, podría retornar resultados inesperados.

documento.write() es una función heredada que puede romper tu página de formas inesperadas y no deberías usarla, a pesar que todavía los navegadores la soportan. Por estas razones, los navegadores han desarrollado técnicas sofisticadas para evitar los problemas de rendimiento causados por el bloqueo de scripts que veremos más adelante.

¿Qué hay del CSS?

JavaScript bloquea el análisis porque modifica el documento. El CSS no puede modificar el documento, entonces parece que no hay razón para bloquear el análisis. ¿Correcto?

Sin embargo, ¿qué pasa si un script pregunta por información del estilo que aún no ha sido cargada? El navegador no sabe qué es lo que el script quiere ejecutar – puede preguntar por cualquier cosa como el background-color del nodo DOM que depende de la hoja de estilo, o puede esperar acceder directamente al CSSOM.

Debido a esto, el CSS puede bloquear el análisis dependiendo del orden de las hojas de estilo externas y scripts en el documento. Si hay hojas de estilo externas localizadas antes de los scripts en el documento, la construcción de los objetos del DOM y del CSSOM pueden interferir una con la otra. Cuando el analizador obtiene una etiqueta de script, la construcción del DOM no puede continuar hasta que el JavaScript termine de ejecutarse, y el JavaScript no puede ser ejecutado hasta que el CSS sea descargado, analizado, y el CSSOM esté disponible.

Otra cosa a tener en mente es que incluso si el CSS no bloquea la construcción del DOM, éste bloquea el renderizado. El navegador no mostrará nada hasta que tenga tanto el DOM como el CSSOM. Esto es porque las páginas sin CSS a menudo no son usables. Si un navegador te mostrara una página desordenada sin CSS y luego, minutos más tarde, se convirtió en una página con estilos, el contenido cambiante y los cambios visuales repentinos generarían una experiencia de usuario turbulenta.

See the Pen Flash of Unstyled Content by Milica (@micikato) on CodePen.

Esta mala experiencia de usuario tiene un nombre – Flash de Contenido Sin Estilo o FOUC (por sus siglas en inglés).

Para evitar estos problemas, debes intentar entregar el CSS tan pronto como sea posible. ¿Recuerdas la popular buena práctica de “estilos en la parte superior, scripts en la parte inferior? ¡Ahora sabes por qué estaba ahí!

De vuelta al futuro – análisis especulativo

Pausar el analizador cuando un script es encontrado, significa que cada script que se cargue retrazará el descubrimiento del resto de recursos que fueron en enlazados en el HTML.

Si tienes unas cuantos scripts e imágenes para cargar, por ejemplo –

<script src="slider.js"></script> <script src="animate.js"></script> <script src="cookie.js"></script> <img src="slide1.png"> <img src="slide2.png">

– el proceso usado para esto era algo así:

Eso cambió al rededor de 2008 cuando IE introdujo algo llamado “lookahead downloader” (o descargador que mira hacia adelante). Esto es una manera de seguir descargando los archivos que eran necesarios mientras los scripts sincrónicos estaban siendo ejecutados. Firefox, Chrome y Safari lo siguieron pronto, y hoy muchos navegadores usan esta técnica bajo diferentes nombres. Chrome y Safari tiene “el scanner de precarga” y Firefox – el analizador especulativo.

La idea es: a pesar que no es seguro construir el DOM mientras se ejecuta un script, todavía se puede analizar el HTML para ver qué otros recursos necesitan ser descargados. Los archivos descubiertos son agregados a la lista y se empieza a descargarlos en segundo plano en conecciones paralelas. Al mismo tiempo que el script termina de ejecutarse, los archivos pueden haber sido descargados.

El gráfico de cascada para el ejemplo anterior ahora se ve como esto:

Las peticiones de descarga iniciadas de esta forma son llamadas “especulativas” ya que es posible que el script cambie la estructura del HTML (¿recuerdas document.write?), resultando en conjeturas desperdiciadas. Aunque esto es posible, no es común, y eso es por qué el análisis especulativo todavía da grandes mejoras en el redimiento.

Mientras otros navegadores solamente precargan los recursos enlazados de esta manera, en Firefox el analizador de HTML también ejecuta el algoritmo de construcción del árbol de DOM de manera especulativa. La ventaja es que cuando la especulación es exitosa, no hay necesidad de analizar el archivo de nuevo para componer el DOM. La desventaja es que hay más trabajo perdido si la especulación falla.

(Pre)cargando cosas

Esta manera de cargar los recursos ofrece un importante aumento del rendimiento, y tú no necesitas hacer algo especial para aprovecharlo. Sin embargo, como un desarrollador web, saber cómo funciona el analizador especulativo puede ayudarte a aprovecharlo al máximo.

El conjunto de cosas que pueden ser precargadas varía entre navegadores. La mayoría de navegadores precarga:

  • scripts
  • CSS externos
  • e imágenes de la etiqueta <img>

Firefox también precarga el atributo poster de los elementos de vídeo, mientras Chrome y Safari precargan las reglas @import de los estilos en línea.

Hay límites para la cantidad de archivos que un navegador puede descargar en paralelo. Los límites varían entre navegadores y dependen de muchos factores, como por ejemplo si estás descargando todos los archivos de uno o varios servidores y si estás usando el protocolo HTTP/1.1 o HTTP/2. Para renderizar la página tan rápido como sea posible, los navegadores optimizan las descargas asignando una prioridad para cada archivo. Para determinar esas prioridades, siguen complejos esquemas basados en el tipo de recurso, posición en la estructura, y el progreso de la página renderizando.

Mientras hace el análisis especulativo, el navegador no ejecuta los bloques de JavaScript en línea. Esto significa que no descubrirá nigún recurso de script insertado, y probablemente éstos sean los últimos en la cola de búsqueda.

var script = document.createElement('script'); script.src = "//somehost.com/widget.js"; document.getElementsByTagName('head')[0].appendChild(script);

Deberías hacer esto más fácil para los navegadores para acceder a los recursos importantes los más pronto posible. Puedes colocarlos en etiquetas HTML o incluir la carga del script en línea y al inicio del documento. Sin embargo, algunas veces quieres que algunos recursos se carguen después porque son menos importantes. En ese caso, puedes ocultarlos del análisis especulativo cargándolos con JavaScript después en el documento.

También puedes revisar esta guía en la MDN Web Docs sobre cómo optimizar tus páginas para el analizador especulativo.

defer y async

Aún, los scripts sincrónicos que bloquean al analizador representan un problema. Y no todos los scripts son igualmente importantes para la experiencia de usuario, como aquellos para seguimimento y análisis. ¿La solución? Hacer posible cargar estos scripts menos importantes, de manera asincrónica.

Los atributos defer y async fueron introducidos para darle a los desarrolladores una manera de decirle al navegador qué scripts manejar asincrónicamente.

Ambos atributos le dicen al navegador que puede continuar con el análisis del HTML mientras carga el script en “segundo plano”, y luego ejecutar el script después que cargue. De esta manera, la descarga del script no bloquea la construcción del DOM y el renderizado de la página. Resultado: el usuario puede ver la página antes que todos los scripts hayan finalizado su carga.

La diferencia entre defer y async es en qué momento se empezará a ejecutar los scripts.

defer fue introducido antes que async. Su ejecución empieza después que el análisis está completamente finalizado, pero antes que se dispare el evento DOMContentLoaded. Esto garantiza que los scripts serán ejecutados en el orden que aparezcan en el HTML y no bloquearán al analizador.

Los scripts con async se ejecutan en la primera oportunidad después que han finalizado la descarga y antes que el evento load de window. Esto significa que es posible (y probable) que los scripts async no sean ejecutados en el orden en que aparecen en el HTML. Esto también significa que pueden interrumpir la construcción DOM.

En donde sea que sean especificados, los scrips con async cargan con baja prioridad. Éstos a menudo cargan después que todos los scripts, sin bloquear la construcción de DOM. Sin embargo, si un script con async finaliza su descarga rápidamente, su ejecución puede bloquear la construcción del DOM y todos los scripts sincrónicos que terminan de descargase depués.

Nota: Los atributos async y defer funcionan solamente para scripts externos. Son ignorados si no hay src.

preload

async y defer son geniales si quieres posponer el manejo de algunos scripts, pero ¿qué pasa con las cosas en tu página web que son críticas para la experiencia del usuario? Los analizadores especulativos son útiles, pero precargan solamente algunos tipos de recursos y siguen su propia lógica. El objetivo general es obtener primero el CSS porque éste bloquea el renderizado. Los scripts sincrónicos siempre tendrán mayor prioridad ante los asincrónicos. Las imágenes visibles dentro de la ventana deberán ser descargadas antes que las que encuentran debajo. Y también hay fuentes, videos, imágenes SVG… En resumen, es complicado.

Como un autor, tú sabes qué recursos son más importantes para renderizar tu página. Algunos de éstos están incluso enterrados en CSS o scripts y eso puede hacer que al navegador le tome un momento antes que los descubra. Para aquellos recursos importantes ahora puedes usar  <link rel="preload"> para comunicar al navegador que quieres cargarlos tan pronto como sea posible.

Todo lo que necesitas es escribir:

<link rel="preload" href="very_important.js" as="script">

Puedes enlazar casi cualquier cosa y el atributo as le dice al navegador que será descargado. Algunos de los posibles valores son:

  • script
  • style
  • image
  • font
  • audio
  • video

Puedes revisar el resto de tipos de contenido en MDN.

Las fuentes son probablemente la cosa más importante que está oculta en CSS. Éstas son críticas para renderizar el texto en la página, pero no pueden ser descargadas hasta que el navegador esté seguro que van a ser usadas. Esta verificación sucede solamente después que el CSS ha sido analizado, aplicado, y que el navegador haya relacionado las reglas CSS con los nodos DOM. Esto pasa bastante tarde en el proceso de carga de la página y resulta en una demora innecesaria en el renderizado del texto. Puedes evitarlo usando el atributo preload cuando enlazas las fuentes.

Una cosa a la que hay que prestar atención cuando precargas fuentes es que también tienes que establecer el atributo crossorigin incluso si las fuentes vienen desde el mismo dominio:

<link rel="preload" href="font.woff" as="font" crossorigin>

La funcionalidad de precarga tiene soporte limitado en los navegadores actualmente, pero puedes revisar el progreso aquí.

Conclusión

Los navegadores son bestias complejas que han estado evolucionando desde los años 90. Hemos cubierto algunas de las peculiaridades desde el legado y de los nuevos estándares en el desarrollo web. Escribiendo tu código con estas guías te ayudará para seleccionar las mejores estrategias para entregar una experiencia de navegación fluida.

Si estás emocionado por aprender más sobre cómo los navegadores funcionan aquí hay algunos otros artículos que debes revisar:

Quantum de cerca: ¿qué es el motor de un navegador web?

Dentro de un super rápido motor CSS: Quantum CSS (alias Stylo)

Categorías: Mozilla Hispano

¡Participa en el Reto de Extensiones para Firefox Quantum!

Noticias de Mozilla Hispano - Jue, 29/03/2018 - 18:41

Esta es una traducción del artículo original publicado en el blog de Mozilla Add-ons.

A los usuarios de Firefox les encanta utilizar extensiones para personalizar su experiencia en la web. Para un desarrollador con conocimiento básico de JavaScript, HTML, y CSS ahora es más fácil que nunca crear extensiones para Firefox con la API WebExtensions. Nuevas y mejoradas APIs para WebExtensions son lanzadas con cada nueva versión de Firefox, dándole a los desarrolladores la libertad para crear nuevas características y refinar sus extensiones.

Estás invitado a usar tus habilidades, conocimiento, y creatividad para crear geniales extensiones nuevas para el Firefox Quantum Extensions Challenge (Reto de Extensiones para Firefox Quantum). Del 15 de marzo al 15 de abril 2018, usa Firefox Developer Edition para crear extensiones que hagan uso de las APIs WebExtensions disponibles en una de las categorías de premiadas. (Las extensiones legado (legacy) que se actualicen a APIs WebExtensions, y extensiones de Chrome que se hayan portado a Firefox desde el 1ro de enero 2018 también pueden participar.)

Un panel de jueces seleccionará tres o cuatro finalistas en cada categoría, y la comunidad será invitada para votar por los ganadores. Anunciaremos los ganadores con el lanzamiento de Firefox 60 en el mes de mayo. Los ganadores de cada categoría recibirán una iPad Pro y promoción de sus extensiones para los usuarios de Firefox. Los segundos lugares recibirán una tarjeta de regalo de Amazon de $250.

¿Listos para iniciar? Visita el sitio del reto para más información (incluyendo las reglas oficiales) y descarga Firefox Developer Edition.

Los ganadores serán notificados a finales del mes de abril, y anunciados al público con el lanzamiento de Firefox 60 en el mes de mayo.

¡Buena suerte!

Categorías: Mozilla Hispano

Adentrándonos en el monitor de red de Firefox (parte 2)

Noticias de Mozilla Hispano - Sáb, 10/03/2018 - 02:02

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Uriel Jurado.

En la publicación pasada, El monitor de red recargado, expusimos las razones por las cuales se rediseñó el Monitor de Red dentro de las herramientas de desarrollador. También aprendimos que usar los estándares de la web para construir herramientas de desarrollo nos permite ejecutarlas en diferentes entornos, cargadas ya sea dentro de la caja de herramientas de desarrollador de Firefox, o bien dentro de una pestaña del navegador como cualquier otra aplicación web.

En este artículo complementario, te mostraremos cómo probarlas y ver el monitor de red en acción.

Obtener el código

El código de las herramientas de desarrollador de Firefox es actualmente parte del repositorio de código de Firefox, así que descargarlo requiere descargar el repositorio completo. Hay muchas maneras de conseguir el código y trabajar en él. Posiblemente podrías iniciar con nuestra documentación de GitHub para obtener instrucciones más detalladas al respecto.

Una opción es usar Mercurial y clonar el repositorio de mozilla-central para obtener una copia local.

# Esto puede tomar un rato ... hg clone https://hg.mozilla.org/mozilla-central cd mozilla-central

Parte de nuestra estrategia de usar los estándares web para desarrollar herramientas para la web también incluye mudar nuestro código de Mercurial a Git (en github.com). Así que, a la larga, la manera de obtener código fuente cambiará permanentemente, y esto hará más fácil y más rápido clonar el código para poder trabajar en él.

Ejecutar la caja de herramientas de desarrollador

Por ahora, si tu deseas compilar el monitor de red y ejecutarlo dentro de la caja de herramientas de desarrollador, debes seguir detalladamente estas instrucciones.

Esencialmente, todo lo que necesitas hacer es usar el comando mach.

cd mozilla-central ./mach build

Después de que la compilación está terminada, ejecuta el binario compilado y abre la caja de herramientas de desarrollador (Herramientas -> Desarrollador web -> Alternar herramientas).

Puedes recompilar rápidamente después de hacer algún cambio al código fuente de la siguiente forma:

./mach build faster Ejecutar servidor de desarrollo

Para poder ejecutar el monitor de red dentro de una página web (función experimental) necesitarás instalar los siguientes paquetes:

Hemos desarrollado un contenedor sencillo que te permite ejecutar las herramientas de desarrollador de Firefox (no solo el monitor de red) dentro de una página web. Se llama Launchpad. Launchpad es responsable de establecer la conexión a la instancia de Firefox que está siendo depurada y de cargar la herramienta del monitor de red.

El siguiente diagrama describe todo el concepto:

  • El monitor de red (cliente) está ejecutándose dentro de una pestaña del navegador (Browser) tal como cualquier otra aplicación web estándar.
  • La aplicación es servida por el servidor de desarrollo (Server) a través de localhost:8000.
  • El monitor de red (cliente) está conectado a la instancia final de Firefox siendo depurada a través de un WebSocket.
  • La instancia final seleccionada de Firefox necesita escuchar el puerto 6080 para permitir que la conexión WebSocket sea creada.
  • El servidor de desarrollo es iniciado usando yarn start

Demos una mirada más a fondo en cómo establecer el entorno de desarrollo.

Primero necesitamos instalar las dependencias para nuestro servidor de desarrollo:

cd mozilla-central cd devtools/client/netmonitor yarn install

Ahora ya podemos ejecutarlo:

yarn start

Si todo está correcto, deberíamos ver el siguiente mensaje:

Development Server Listening at http://localhost:8000

Después, necesitamos escuchar las conexiones entrantes dentro de nuestro navegador Firefox que deseamos depurar. Abrimos la caja de herramientas de desarrollador (Herramientas -> Desarrollador web -> Caja de herramientas de desarrolladores) y escribir el siguiente comando dentro de ella. Esto iniciará el monitoreo, tal que las herramientas puedan conectarse a este navegador.

listen 6080

La interfaz de la caja de herramientas de desarrolladores debería ser abierta al fondo de la ventana del navegador.

Finalmente, puedes cargar localhost:8000

Ahora tu deberías de ver la interfaz de usuario de Launchpad, la cual lista las pestañas abiertas del navegador Firefox seleccionado. Deberías también de ver cuál de esas pestañas es el Launchpad en sí (la última pestaña del navegador ejecutándose desde localhost:8000)

Todo lo que necesitas hacer es dar click en la pestaña que deseas depurar. Tan pronto como Launchpad y las herramientas del monitor de red se conecten a la pestaña del navegador seleccionada, puedes recargar la pestaña conectada y ver una lista de las peticiones HTTP.

Si cambias el código subyacente y recargas la página, verás tus cambios inmediatamente.

Dale un vistazo a nuestro siguiente vídeo para un detallado paso a paso de la puesta en marcha de la herramienta monitor de red sobre el Launchpad y sobre cómo utilizar la asombrosa característica de recarga para ver los cambios del código instantáneamente.

Igualmente podrías querer revisar mozilla-central/devtools/client/netmonitor/README.md para información más detallada acerca de cómo compilar y ejecutar la herramienta monitor de red.

Planes a futuro

¡Creemos que construir herramientas para la web usando tecnologías web estándares es el camino correcto a seguir! Nuestras herramientas son para desarrolladores web. Nos gustaría que fueras capaz de trabajar con nuestras herramientas usando las mismas habilidades y conocimientos que aplicas cuando desarrollas aplicaciones y servicios web.

Estamos planeando muchas más poderosas características para las herramientas de desarrollador de Firefox, y creemos que el futuro nos espera con muchas más cosas emocionantes. Aquí hay un adelanto de lo que está por venir:

  • Conexión con Chrome
  • Conexión con NodeJS
  • Integración con IDEs existentes

¡Mantente al tanto!

Categorías: Mozilla Hispano

Tablas de importación de WebAssembly … ¿Qué son?

Noticias de Mozilla Hispano - Jue, 22/02/2018 - 01:47

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

En un artículo anterior, te introducimos a las cuatro formas de importación que puede poseer una instancia de WebAssembly:

  • Valores (values)
  • Funciones de cierre (function imports)
  • Memoria (memory)
  • Tablas (tables)

La última probablemente era un poco desconocida. ¿Qué es una tabla de importación y para qué se usa?

A veces en un programa te gustaría tener una variable que apunta a una función, por ejemplo para que se ejecute luego de una acción, como los callbacks. Entonces puedes así pasarla a otra función.

En C, esto se llama punteros de funciones. La función reside en memoria. La variable, el puntero a la función, solo apunta a esa dirección de memoria.

Y si lo necesitas, puedes apuntar a la variable a otra función. Este concepto debería ser familiar.

En las páginas web, todas las funciones son solo objetos de JavaScript. Y por ello, residen en direcciones de memoria que están fuera de la memoria de WebAssembly.

Si quieres tener una variable que apunte a una de estas funciones, necesitamos tomar su dirección y ponerla en nuestra memoria.

Pero parte de mantener las páginas web seguras es asegurarse de esconder esas direcciones. No quieres que el código de la página tenga posibilidad de ver o manipular las direcciones de memoria. Si hay código malicioso, se puede usar para conocer cosas que estén en memoria y crearía una vulnerabilidad.

Por ejemplo, se podría cambiar la dirección que tienes de una función y apuntarla a otro lugar. Entonces cuando intentes llamar a esa función, en vez de cargarla ejecutaría la dirección que tu atacante te modificó.

Esto podría permitir que código malicioso se inserte en memoria, tal vez dentro de una cadena de texto. Las tablas hacen posible tener punteros de función, pero de una forma que no sean vulnerables a este tipo de ataques.

Una tabla es un arreglo que vive fuera de la memoria de WebAssembly, donde los valores son referencias a funciones.

Internamente, estas referencias contienen direcciones de memoria, pero como no están dentro de la memoria de WebAssembly, WebAssembly no puede ver esas direcciones. Solo tiene acceso a los índices del arreglo.

Si el módulo de WebAssembly desea llamar a una de estas funciones, pasa el índice a una operación llamada call_indirect. Ésta llamará a la función.

Actualmente el uso para las tablas es un poco limitado. Fueron añadidas a la especificación para soportar los punteros de funciones, porque normalmente C y C++ suelen usar este tipo de cosas. Por ello, los únicos tipos de referencias que puedes colocar en una tabla son referencias a funciones. Pero conforme las posibilidades de WebAssembly se expandan, por ejemplo, cuando se añada el acceso directo al DOM, podrás ver otro tipo de referencias almacenadas en las tablas y otras operaciones en las tablas, adicionalmente a call_indirect.

Categorías: Mozilla Hispano

Ve más allá de console.log con el depurador de Firefox

Noticias de Mozilla Hispano - Sáb, 10/02/2018 - 18:04

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

console.log no es un depurador. Es genial para averiguar qué está haciendo tu aplicación JavaScript, pero se limita a escupir una cantidad mínima de información. Si tu código es complejo, necesitarás un depurador adecuado. Es por eso que hemos agregado una nueva sección a el Firefox DevTools Playground, que trata sobre la depuración. Hemos creado cuatro lecciones básicas que usan el depurador de Firefox para examinar y arreglar una aplicación de tareas (to-do) en JavaScript.

Presentamos el Debugger Playground

Las lecciones son completamente gratuitas y el código de la aplicación de tareas está disponible para descargar desde GitHub.

Estas lecciones son un nuevo formato para nosotros y estamos muy emocionados de brindártelas. Siempre estamos buscando nuevas formas para ayudar a los desarrolladores a aprender cosas y mejorar el flujo de trabajo diario. Si tienes una idea, avísanos. Ampliaremos el Playground en los próximos meses y estamos encantados en escuchar de desarrolladores como tú.

Si no estas familiarizado con el depurador de Firefox, echa un vistazo a los documentos de depuración en MDN y mira este corto de introducción:

Ahora echemos un vistazo a una lección del nuevo Debugger Playground. ¿Alguna vez usaste console.log para saber el valor de una variable? Hay una manera más fácil y más precisa de hacerlo con el depurador.

Usa el depurador para saber el valor de una variable

Es mucho más fácil encontrar una variable con el depurador de Firefox que con console.log. Así es cómo funciona:

Echemos un vistazo a una aplicación sencilla de tareas. Abre la aplicación de tareas en una nueva pestaña.

Esta aplicación tiene una función llamada addTodo que tomará el valor del formulario de entrada, creará un objeto y luego lo insertará en un array de tareas. Probémoslo agregando una nueva tarea. Esperarás tener esta nueva tarea agregada a la lista, pero en su lugar verás “[object HTMLInputElement]”.

Algo está roto, y tenemos que depurar el código. La tentación es comenzar a agregar console.log por toda la función, para identificar dónde está el problema. El enfoque podría ser algo como esto:

const addTodo = e => { e.preventDefault(); const title = document.querySelector(".todo__input"); console.log('title is: ', title); const todo = { title }; console.log('todo is: ', todo'); items.push(todo); saveList(); console.log(‘The updated to-do list is: ‘, items); document.querySelector(".todo__add").reset(); };

Esto puede funcionar, pero es engorroso e incómodo. También debemos recordar eliminar estas líneas después de corregir el código. Hay una forma mucho mejor de hacerlo con el depurador utilizando lo que se llama un punto de interrupción…

Aprende más en el Debugger Playground

El Debugger Playground cubre los aspectos básicos del uso del depurador de Firefox, examinar la pila de llamadas, establecer puntos de interrupción condicionales y más. Sabemos que hay una curva de aprendizaje abrupta para usar el depurador (y para depurar JavaScript), por lo que hemos creado una aplicación de tareas fácil de entender y decodificar. También es útil ejecutarlo en tu navegador web para mantener las cosas en orden durante tu día de trabajo. La aplicación está disponible aquí para descargar en GitHub. Tómalo y luego dirígete a el Playground para ver las lecciones.

Haznos saber qué te gustaría ver a continuación. Estamos trabajando en nuevas lecciones sobre las últimas tecnologías web y nos gustaría saber de ti. Publica en los comentarios que hay a continuación.

Categorías: Mozilla Hispano
Subscribe to Proyecto NAVE aggregator - Mozilla Hispano