Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

392
Vistas
nodeIntegration vs preload.js vs IPC en Electron

He leído los documentos de aislamiento de contexto , IPC y seguridad de Electron, junto con esta publicación sobre el uso de nodeIntegration y esta publicación sobre preload.js . Parece que hay muchas formas diferentes de realizar tareas similares y no estoy seguro de cuál es la mejor (segura, fácil, etc.).

Sé que simplemente puede habilitar nodeIntegration en los procesos del renderizador para acceder a Node fuera del proceso principal. Todas las fuentes recomendaron en contra de eso en su mayor parte.

Aquí es donde estoy confundido. Un ejemplo de la documentación de Electron dice que puede hacer algo como lo que se muestra a continuación.

precargar.js

 // preload with contextIsolation disabled window.myAPI = { doAThing: () => {} }

renderizador.js

 // use the exposed API in the renderer window.myAPI.doAThing()

preload.js tiene acceso a las API de Node, por lo que técnicamente podría cargar todos los procesos de Node y luego acceder a ellos en mis procesadores.

Sin embargo, también leí sobre IPC.

parte de main.js

 ipcMain.on('set-title', (event, title) => { const webContents = event.sender const win = BrowserWindow.fromWebContents(webContents) win.setTitle(title) })

precargar.js

 const { contextBridge, ipcRenderer } = require('electron') contextBridge.exposeInMainWorld('electronAPI', { setTitle: (title) => ipcRenderer.send('set-title', title) })

renderizador.js

 const setButton = document.getElementById('btn') const titleInput = document.getElementById('title') setButton.addEventListener('click', () => { const title = titleInput.value window.electronAPI.setTitle(title) });

Por ejemplo, digamos que quiero implementar una función usando un módulo npm externo. ¿Lo incorporaría en preload.js y lo llamaría desde mi renderizador, o lo incorporaría en main.js, usaría ipcRenderer en preload.js con un canal para la función y luego lo llamaría desde mi renderer?

about 4 years ago · Juan Pablo Isaza
2 Respuestas
Responde la pregunta

0

preload.js tiene acceso a las API de Node, por lo que técnicamente podría cargar todos los procesos de Node y luego acceder a ellos en mis procesadores.

Esto no siempre es cierto en realidad. Si la zona de sandbox está habilitada, solo se puede acceder a un subconjunto de las API de nodo en la precarga. Fuente : (énfasis añadido)

las secuencias de comandos precargadas adjuntas a los renderizadores en espacio aislado seguirán teniendo un subconjunto polillenado de API de Node.js disponible

Si está utilizando un módulo sandbox externo y la zona de pruebas está habilitada (probablemente debería estarlo), entonces no podrá importar el módulo npm en su script de precarga y tendrá que usar ipc y activarlo en el proceso principal.

Si la zona de sandbox está deshabilitada y puede lograr todo lo que desea del proceso de representación, entonces diría que solo importe el módulo en su precarga y lo use directamente.

about 4 years ago · Juan Pablo Isaza Denunciar

0

El código que pegó del documento Context Isolation muestra cómo podría usar métodos y módulos expuestos (a través de precarga) al renderizador en versiones anteriores de electron, antes de que el aislamiento de contexto se configurara como verdadero de forma predeterminada. Sin embargo, no es así como debes hacerlo. Con contextisolation = true , debe usar contextbridge en su precarga, porque los objetos de la ventana se mantienen aislados.

Entonces, el código que pegó de IPC es la forma en que debe hacerlo en 2022. También mantendría mis dedos alejados de NodeIntegration, a menos que realmente sepa lo que está haciendo.

Con respecto a su última pregunta: generalmente seguiría un enfoque de privilegio mínimo. Cuanto menos potencia le des al renderizador, más seguro.

Te daré un ejemplo de mi proyecto reciente. Necesito hacer capturas de pantalla y luego guardarlas en algún lugar. Para eso necesito Browserwindow.webcontents.capturePage() y fs.writeFile() , que solo están disponibles para el proceso principal. Definitivamente sería arriesgado exponer el método fs.writeFile al renderizador, así que no lo haré. En cambio, mantengo mi lógica para escribir las capturas de pantalla en mi sistema de archivos en el proceso principal. Sin embargo, quiero iniciar las capturas de pantalla desde el renderizador (mi interfaz de usuario). Para exponer lo menos posible, solo expongo una función que llama al método de invocación en contextBridge de precarga que se ve así:

 contextBridge.exposeInMainWorld("ipcRenderer", { invokeSnap: async (optionsString: string) => await ipcRenderer.invoke("snap", optionsString), });

En main, tengo un oyente que maneja la solicitud entrante:

 ipcMain.handle("snap", async (_event, props: string) => { // screenshot logic return //sth that the renderer will receive back once the process is finished; });

El renderizador envía la solicitud y maneja la respuesta o errores como ese:

 window.ipcRenderer.invokeOpen(JSON.stringify(options)) .then(...) .catch(...)

Como efecto secundario, esto pone gran peso en el proceso principal, lo que podría no ser deseable en proyectos más grandes, no sé. Tal vez un desarrollador de electrones con más experiencia pueda decir más al respecto.

about 4 years ago · Juan Pablo Isaza Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda