Construyendo Aplicaciones de Escritorio a Partir de Aplicaciones Web: Escalando Electron con Firma de Código y CI/CD

Hola a todos. Gracias por unirse a mi sesión de hoy. Hablaré sobre la construcción de aplicaciones de profundidad a partir de aplicaciones web y también sobre la escalabilidad de aplicaciones industriales con firma de código y CI CD multiplataforma. Mi nombre es Ayole Aonseola, soy arquitecto de soluciones y también el defensor principal de desarrolladores. Tienes una aplicación web y quieres convertirla en una aplicación orientada a escritorio. Entonces, Electron te ayuda a envolver esta aplicación web existente en lo que puedes servir a los usuarios en un escritorio o como una aplicación de escritorio.

Pero hay un desafío cuando quieres pasar del modo de desarrollo al modo de envío. Necesitas un muro para la firma y CI CD. Así que estos dos muros pueden causar problemas cuando intentas convertir una aplicación web en una aplicación de escritorio. Hay historias comunes que podrían suceder cuando estás tratando de construir. Una de las historias es cuando los usuarios intentan instalar la aplicación y se encuentran con un mensaje emergente que dice que el desarrollador de esta aplicación no está verificado, o construyes en tu Mac pero intentas dar esa misma aplicación a otro usuario que está usando otro Mac, pero no funciona en su Mac.

O digamos, por ejemplo, que lo construyes en una aplicación de la serie M o un Mac de la serie M, lo que significa que estás usando M1, M2, y le das a un usuario que está usando un procesador Intel. Ahora, puede que no funcione porque estos son dos chips de procesamiento distintos. O construyes en Windows y quieres que ese mismo archivo que estás construyendo para Mac se construya en Windows. Así que estos son algunos desafíos que podrías encontrar. Otro desafío es cómo firmamos la aplicación para poder evitar ese desarrollador no verificado. Así que el problema no es solo construir una aplicación. El problema es cómo podemos escalar esta aplicación con confianza?

Porque todo lo que necesitamos hacer es obtener la URL de la aplicación desplegada y luego envolverla con Electron para servir a los usuarios de escritorio. Hay una arquitectura que necesitas seguir cuando estás construyendo para usuarios de escritorio usando Electron. Y Electron te da algunas funcionalidades básicas que te permiten también poner la seguridad primero, o déjame decir, construir una capa de seguridad alrededor de tu aplicación de escritorio. Una de ellas es el aislamiento de contexto. Si activas esta funcionalidad, que está configurada en true, crea una barrera segura entre tu página web y tu back-end, forzando toda la comunicación a través de un puente seguro y predefinido. De esta manera, nada pasa sin tu control.

Electron te da una arquitectura que te permite poner la capa de seguridad primero cuando estás construyendo tu aplicación de escritorio. Y una de estas capas es el aislamiento de contexto. Así que esta funcionalidad, si la configuras en true, crea una barrera entre el código de tu página web y tus potentes APIs de back-end, forzando toda la comunicación a pasar por un puente seguro y predefinido. Así que si la comunicación no pasa por esta ruta, no tendrá éxito. Eso es lo que el aislamiento de contexto hace por ti. Además, la integración de node te ayuda a deshabilitar la funcionalidad de Node.js en el front-end de tu aplicación. Así que está previniendo que los scripts de la página web accedan directamente a los archivos de tu computadora. Así que cualquier archivo peligroso que esté intentando ejecutarse, para tener acceso a los archivos de tu computadora, una vez que esta integración de node se configura en false, asegura que no haya archivos defectuosos o scripts que estén destinados a AMP para tus usuarios que están usando aplicaciones de escritorio no se hagan realidad. Así que eso debería configurarse en false. Así que eso cubre esa parte.

Y la tercera funcionalidad es la validación de mensajes IPC. Así que esto es solo una práctica, asegurando que tu back-end esté verificando todos los datos. Así que más como sanitizar todos los datos que han sido enviados desde el front-end al back-end, o cada comunicación ha sido sanitizada para asegurar que no haya trucos para realizar acciones inseguras. Así que en este proceso, tus usuarios de escritorio han sido protegidos a toda costa. Después de que hayas terminado con el fondo, hemos podido establecer un fondo de este contenido. Luego, cuando estás construyendo, también hay algo que necesitas considerar, que son los desafíos de ingeniería. Uno de los cuales es la firma. Así que cuando tu aplicación no está firmada, tus usuarios tienden a ver advertencias de aplicación no confiable, y esto les permite instalar tu aplicación, ya sea para usuarios de Mac o de Windows. También para la distribución, necesitas distribuir para múltiples sistemas operativos, porque no quieres construir solo para un sistema operativo específico. Al menos quieres construir para Windows, quieres construir para Linux, y también quieres construir para usuarios de Windows. Así que lo que significa que la distribución también es clave. Además, la automatización también es algo que necesitas considerar. ¿Por qué? Porque no quieres permitir que ocurran errores humanos durante tus lanzamientos. Así que estos son los desafíos de ingeniería que necesitan ser considerados.

Así que estos son los desafíos de ingeniería que deben ser considerados. Firma, distribución y automatización. Ahora, ¿qué es escalar? ¿Qué significa realmente? Hay un lugar para la confianza, hay un lugar para la automatización, y también hay un lugar para la seguridad. Si a tu aplicación le falta la confianza que necesita, tus usuarios no instalarán la aplicación. Y si algunos procesos no están automatizados, habrá fricción entre tus equipos, y tu tiempo de salida al mercado se verá afectado. Además, la seguridad es sinónimo de confianza. Así como la confianza reduce el conteo de instalaciones de la aplicación, la seguridad también asegura que tu aplicación pierda su credibilidad en el mercado. Lo que significa que también tienes que construir una fuerte confianza, asegurar que la automatización sea consistente, y que tu seguridad esté a un nivel muy alto. Por eso defino escalar como confianza multiplicada por automatización multiplicada por seguridad. Esto te da una aplicación escalada que puede servir a múltiples usuarios, o miles de usuarios, donde tu confianza está protegida, tu seguridad también está protegida, y tu automatización está bien orientada.

Ahora, firma de código. He estado mencionando la firma de código desde el comienzo de esta charla. ¿Qué es la firma de código, y por qué la necesitamos? Entonces, la firma de código verifica quién construyó la aplicación, y que no fue manipulada. Busca un ejemplo, compramos un teléfono nuevo, y cuando estás a punto de abrir este teléfono, notas que el sello ha sido manipulado. Así que eso es lo que asegura la firma con tu aplicación. Ya sea para dispositivos Apple o para dispositivos Windows, te permitirá instalar una aplicación que ha sido firmada. Así que por defecto, si una aplicación no está firmada, la aplicación muestra a los usuarios un diálogo que dice que el desarrollador de la aplicación no es confiable. Así que, la firma no es decoración. Es el pasaporte que tu aplicación necesita para acceder a múltiples sistemas operativos.

Ahora, tomemos Apple antes de ir a Windows. Así que, para la cadena de confianza de Apple, necesitas developer ID, necesitas developer ID installer. Así que, estos son los certificados que necesitas descargar de tu cuenta de desarrollador en Apple. Así que, lo primero que necesitas hacer es registrarte como desarrollador de Apple, luego iniciar sesión en tu cuenta, luego bajo tus configuraciones, podrás descargar la certificación de aplicación developer ID. Así que, esto te permite poder distribuir un .dmg, que es el archivo ejecutable de Apple, así que te permite distribuir el archivo .dmg. Luego, el segundo certificado es developer ID installer, ambos están ahí. Así que, descargas el certificado, y luego en tu máquina local, puedes instalarlo. Y si estás usando CI, asegúrate de que el certificado esté subido en tu pipeline de CI. Luego, la autorización de la aplicación es esencial porque cuando estás tratando de vincular tu aplicación en una aplicación ejecutable, el sistema operativo de Apple escanea y valida tu build. Así que, de esta manera, la autorización convierte tu aplicación en sitio en una aplicación confiable del sistema operativo Mac. Así que, para Apple, necesitas certificados de aplicación developer ID, necesitas certificados de installer developer ID, y así necesitas la autorización de la aplicación.

Así que, preparé un código de ejemplo que muestra las ideas principales. Entonces, en este código de ejemplo, estoy convirtiendo mi blog en una aplicación de escritorio, y tiene múltiples secciones. La primera sección es crear una instancia, así que creo la ventana y configuro la ventana predeterminada con un ancho de 800 y una altura de 600. Entonces, en este proceso, cuando no hay nada que mostrar, tus usuarios no verán nada, pero inmediatamente hay algo que mostrar. Entonces, en lugar de un destello en la pantalla, es cuando está listo para mostrar, ese es el momento en que tu aplicación se carga completamente y los usuarios pueden realmente ver cualquier píxel en la pantalla. Es entonces cuando tu aplicación se abrirá al tamaño máximo de pantalla de la máquina de tu usuario.

Entonces, después de que eso esté hecho, también hay una función when ready que dice que cuando la ventana esté lista, entonces realiza esta acción. Entonces, open at login, open at login. Así que, estas son funcionalidades que están disponibles en Mac y también creé otra función que dice window all closed, que dice que el proceso de la plataforma no es igual a Darwin absoluto. Así que, estos son solo comandos de Mac que permiten que el Electron pueda funcionar como una aplicación de Mac. Y responde a todas las acciones de Mac. Cierras la aplicación, luego se da un espacio en el árbol de tu entorno Mac, para que en cualquier momento que quieras hacer clic, puedas abrir automáticamente el entorno.

Cierras la aplicación, luego se da un espacio en el árbol de tu entorno Mac, para que en cualquier momento que quieras hacer clic, puedas abrir automáticamente el entorno. Entonces, esto es lo que todas estas acciones están haciendo, y para Windows, estamos tratando de ver que inmediatamente el sistema se encienda, la aplicación se abra automáticamente. Así que, eso es lo que esto estará haciendo.

Entonces, este es el archivo main.js, y todo está listo para ser empaquetado en una aplicación diferente con este pequeño código. Ahora, creé un archivo notarized.js. Lo que hace esto es que, como estoy construyendo para Mac, he creado el ID del paquete de la aplicación, donde se guardará la aplicación y luego el nombre de la aplicación. Además, se necesita tu ID de aplicación. Luego, necesitas crear una contraseña específica de Apple para tu aplicación. Así que, bajo tu cuenta de Apple, vas a configuraciones. Bajo seguridad, necesitas generar un ID específico de la aplicación, no la contraseña para tu cuenta de desarrollador. Así que, esto es específico para una aplicación. Entonces, generas esta contraseña. Si la hago de corta duración o de larga duración, entonces generas esta contraseña. Esa es la contraseña que necesitas para este proceso. Luego, agregas tu ID de equipo.

Así que, tu ID de equipo siempre está disponible en tu cuenta de desarrollador. Cada vez que inicias sesión, ves que tu ID de equipo siempre se muestra. Así que, una vez que tienes este ID de equipo, agrégalo a tu archivo env, pon tu Apple ID, que puede ser tu correo electrónico, luego pon la contraseña específica de la aplicación. Recuerda, esta no es la contraseña para tu cuenta de desarrollador. Así que, esto es específico para una aplicación. Así que, usas eso y también agregas tu ID de equipo. Entonces, estás listo. No olvides que ya agregamos el certificado descargado, el ID de la aplicación y luego el ID del instalador. Esos dos son muy esenciales en este proceso. Así que, una vez que todo eso está disponible en tu máquina local, cuando ejecutas npm run dist, automáticamente construye y Apple escanea el archivo de autorización y asegura que todo funcione bien. En menos de dos minutos, estás al día.

Así que, añadí el archivo packet.json para que puedas ver lo que hay en mi archivo packet.json. En ese lugar, añadí el nombre del autor, la dirección de correo electrónico en la que puedes contactarme, y también añadí que esta hermosa aplicación de Mac debería ser universal. Ya sea que estés usando un procesador Intel o estés usando la serie M, este instalador funciona para todo porque es universal. Y en esta configuración también, configuré para Windows también porque este código también se puede usar tanto para Mac como para Windows. Así que, ejecuta uno, usa eso para construir múltiples sistemas operativos. Así que, con este archivo, podemos construir tanto para Mac como para Windows. Por eso añadí el archivo packet.json para que pudieras ver cómo se ve.

Ahora, para Windows, he explicado cómo necesitamos construir nuestro entorno para construir para Mac. Entonces, ¿cómo construimos para Windows? Así que, construir para Windows, Windows no tiene una cuenta de desarrollador como lo hace Apple. Así que, es un juego diferente, lo que significa que necesitas un certificado para firmar tu aplicación. Así que, la última vez que construí, compré un certificado de instalador de Digisat y es un certificado EV. Así que, me dieron un token USB porque eso fue lo que solicité. Ahora, puedes decidir optar por un token USB físico o puedes optar por un token HSM, que se puede instalar en tu infraestructura en la nube. Así que, si optas por un token físico, la primera vez que quieras construir tu aplicación, conectas tu token USB al PC y luego construyes, y tu sistema o tu aplicación escanea automáticamente o busca el certificado y firma tu aplicación con él. Y si es HSM, inmediatamente estás tratando de construir para tu pipeline de CI. Inmediatamente activas una construcción. Intenta localizar el instalador. Intenta también localizar el certificado y luego asegúrate de que todo esté firmado y estés listo para continuar.

Así que, la razón por la que Windows es diferente es porque Mac opera en un nivel diferente. Windows también opera en un nivel diferente. Así que, necesitas considerar que si estás construyendo para estos dos sistemas operativos, necesitas considerar lo que funciona para estos dos sistemas operativos. Así que, inmediatamente obtienes tus certificados, puede haber una aplicación que necesites instalar ya sea en la infraestructura en la nube o en tu máquina local. Cuando instalas esto, esa aplicación permite que tu aplicación pueda acceder al certificado desde tu PC. Porque si conectas el token a tu PC, es posible que no puedas ver nada. Así que, este token permite que ese certificado en tu PC sea visto y pueda ser accedido por la aplicación para firmar la aplicación. Así que, he explicado que puedes hacerlo localmente y también puedes hacerlo en la nube. Así que, para aplicaciones en la nube o para los procesos en la nube, se puede hacer de dos maneras. Esto se debe a que tu nube no puede acceder al token USB físico, lo que significa que hay una necesidad de buscar una manera de acceder a tu token USB. Así que, por eso mencioné HSM. Así que, puedes optar por Self-Posted Runner, donde tienes una infraestructura on-prem, donde puedes conectar físicamente el token USB, o si no tienes ninguna infraestructura on-prem, todo es en la nube, entonces puedes usar una infraestructura digital donde obtienes el equivalente HSM del token USB, y luego el certificado se instala y almacena de manera segura.

Ahora, de esta manera, estamos tratando de automatizar el proceso de firma, trasladando el poder de los esfuerzos humanos a los esfuerzos del proceso de CI. Así que, eso es lo que estamos haciendo y manejando el token EV de manera eficiente. Así que, este es un flujo de trabajo de muestra para estamos tratando de usar el módulo HSM que es nuestro certificado que se está almacenando en una infraestructura en la nube. Así que, estoy asumiendo que estoy usando GitHub y Azure. Así que, esta es solo una configuración única, y después de la configuración, cada vez que quieras construir, no necesitas hacer la configuración de nuevo, porque tu archivo YAML está ahí, y cada vez que empujas una etiqueta, automáticamente construye algo para tus procesos. Así que, envías certificados después de que se haya realizado tu compra, y luego cargas de manera segura los certificados, incluyendo la clave privada y la clave pública a tus almacenes de claves de Azure, entonces este servicio en la nube está diseñado para gestionar secretos y certificados.

Así que, si hay un almacén de claves de Azure, lo hace. Sé que AWS también tiene algo similar a eso que también puedes usar para asegurar tu clave. Así que, en tu Azure, creas un principio de servicio que actúa como humano en nombre de tu pipeline de CI. Así que, solo le otorgas a ese principio un acceso para certificados específicos y realiza la firma en tu nombre. Así que, ese principio no puede eliminar o exportar la clave. Lo único que podría hacer es solo firmar tu aplicación. Así que, en GitHub, también puedes crear un secreto mediante el cual copias el ID del principio de servicio, copias el ID del inquilino y el secreto, y usas eso para iniciar sesión en la plataforma de Azure durante tu proceso de CI.

Así que, por eso puse comentarios en algunas partes del archivo de flujo de trabajo. Así que, hay un disparador que se activa para que la vista ocurra, luego hay un inicio de sesión en los entornos de Azure, luego se lleva a cabo la firma, y después de que la firma se lleva a cabo, automáticamente la aplicación se carga en tu almacenamiento y artefactos deseados que puedes distribuir. Así que, ahora, cada vez que empujas un nuevo código, tus flujos de trabajo de GitHub Actions se ejecutan automáticamente y pueden firmar tu aplicación en la nube usando tu CI. Así que, estas son las dos formas en que puedes firmar tu aplicación. O lo haces físicamente conectando el token de hardware físico a tu PC en el momento en que estás ejecutando tu proceso de construcción, o lo haces en tu pipeline de CI porque tu certificado está en la nube. Así que, tu archivo de flujo de trabajo identifica automáticamente las credenciales de inicio de sesión y puede firmar en nombre de tu usuario.

La esencia de esto es que, con CICD, necesitas un empuje y todas las compilaciones pueden realizarse. Así que, sin firma manual, cada compilación, haz una compilación tanto para tus usuarios de Windows como para tus usuarios de Mac, y luego los artefactos respectivos se cargan automáticamente en la ruta que esperas. Entonces, en lugar de hacer esto manualmente, esperamos que esto se haga automáticamente.

Ahora, ¿cuál es la buena captura? Esperaba que enviaras tus certificados a tu repositorio o a tu infraestructura de cliente en Base64. Entonces, ¿por qué elegimos Base64? Todos sabemos que este es un esquema de codificación que convierte datos binarios en una cadena de solo texto y te permite copiar todo el certificado y pegarlo en los secretos de tu repositorio, probablemente tal vez como tu secreto de GitHub. De esta manera, puede ser leído por tu flujo de trabajo de CI.

Ahora, otra cosa que también espero que hagas es que no actives tu proceso de CI para esta compilación en cada empuje. Entonces, puedes activar este proceso de compilación en un empuje de etiqueta. Entonces, probablemente tu desarrollador empuje una etiqueta, digamos, versión v1.0, y automáticamente eso ejecuta el proceso de compilación y firma. De esta manera, sabes cuándo estás construyendo para prueba, modo de desarrollo, y cuándo estás construyendo para candidatos de lanzamiento. Entonces, cuando estás construyendo para lanzamiento, todo lo que necesitas empujar es una etiqueta y eso ejecutará automáticamente tu archivo de flujo de trabajo.