@glassnote/client 2.4.16 → 2.4.18

package/INSTALACION.md

@@ -63,19 +63,19 @@ donde la app los busca, y el cliente arranca ya conectado.
 ```sh
 # Linux / macOS — ojo con el `-s --`, es lo que hace que sh le pase las banderas al script
 curl -fsSL https://glassnote.intermark.ec/install.sh | sh -s -- \
-  --org-id 55 --api-key <clave> --device-name "Caja 01" --user-name "Santiago"
+  --org-id <id> --api-key <clave> --device-name "Caja 01" --user-name "Santiago"
 ```
 
 ```powershell
 # Windows — con parámetros: `[scriptblock]` es lo que deja pasárselos al script bajado
 & ([scriptblock]::Create((irm https://glassnote.intermark.ec/install.ps1))) `
-  -OrgId 55 -ApiKey <clave> -DeviceName 'Caja 01' -UserName 'Santiago'
+  -OrgId <id> -ApiKey <clave> -DeviceName 'Caja 01' -UserName 'Santiago'
 ```
 
 ```powershell
 # Windows — con variables de entorno: `irm | iex` no deja pasar parámetros, pero el
 # cliente lee las variables (quedan puestas en esa ventana de PowerShell)
-$env:GLASSNOTE_ORG_ID='55'; $env:GLASSNOTE_API_KEY='<clave>'; $env:GLASSNOTE_DEVICE_NAME='Caja 01'; $env:GLASSNOTE_USER_NAME='Santiago'
+$env:GLASSNOTE_ORG_ID='<id>'; $env:GLASSNOTE_API_KEY='<clave>'; $env:GLASSNOTE_DEVICE_NAME='Caja 01'; $env:GLASSNOTE_USER_NAME='Santiago'
 irm https://glassnote.intermark.ec/install.ps1 | iex
 ```
 
@@ -98,6 +98,60 @@ Es el diseño: en GlassNote un dispositivo es un usuario en un equipo. Dos usuar
 misma máquina son dos dispositivos en el tablero, cada uno con su `device-id`, y cada
 cliente corre mientras su usuario tiene la sesión abierta.
 
+Para SCCM/Microsoft Configuration Manager en producción hay dos formas, con el mismo
+paquete offline adentro:
+
+| Forma | Cuándo |
+|---|---|
+| **MSI** `glassnote-client-offline.msi` | La recomendada para Configuration Manager e Intune. Se importa como aplicación *Windows Installer*. Lleva el paquete adentro: el equipo no descarga nada. La detección hay que cambiarla a la marca del registro (ver la guía de SCCM). |
+| Bootstrap `install-glassnote-sccm.ps1` | Cuando no se quiere poner 145 MB en el punto de distribución: el script baja el ZIP desde `glassnote.intermark.ec` en cada equipo. |
+
+### El MSI
+
+```text
+https://glassnote.intermark.ec/glassnote-client-offline.msi
+```
+
+Instalar y desinstalar:
+
+```text
+msiexec /i glassnote-client-offline.msi GLASSNOTE_ORG_ID=<id> GLASSNOTE_API_KEY=<clave> /qn
+msiexec /x {ProductCode} /qn
+```
+
+El ProductCode cambia con cada paquete, así que no se escribe a mano: para desinstalar,
+búsquelo en `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall` por el nombre
+`GlassNote Client (offline)`. Propiedades: `GLASSNOTE_ORG_ID` y `GLASSNOTE_API_KEY`
+(obligatorias), `GLASSNOTE_API_URL`, `GLASSNOTE_WS_URL`, `GLASSNOTE_DEVICE_NAME`,
+`GLASSNOTE_USER_NAME`. Sin el alta la instalación falla con 1603 y no deja nada.
+
+Un paquete nuevo reemplaza al anterior aunque sea la misma versión del cliente, y volver
+a lanzar el mismo paquete repara un equipo donde el producto figura instalado pero el
+cliente no está.
+
+El MSI se instala por equipo, pero el cliente es por usuario: la instalación corre como
+SYSTEM, busca al usuario con sesión iniciada e instala en su sesión, espera y devuelve su
+código de salida. **Sin nadie con sesión iniciada no instala** y msiexec devuelve error.
+Desinstalar quita el cliente del usuario, el autoarranque y los archivos del paquete;
+**no toca `%APPDATA%\glassnote`**, así que reinstalar deja el mismo dispositivo.
+
+### El bootstrap
+
+```text
+https://glassnote.intermark.ec/install-glassnote-sccm.ps1
+```
+
+Ese bootstrap descarga:
+
+```text
+https://glassnote.intermark.ec/glassnote-sccm-offline-runtime.zip
+```
+
+El ZIP lo genera GitHub Actions durante el deploy de `glassnote-next` e incluye Node.js
+portable, Electron, cache npm y `glassnote-client-2.4.17.tgz`. Así la instalación inicial
+no depende de `nodejs.org`, GitHub ni `registry.npmjs.org`. El `install.ps1` genérico queda
+para instalaciones manuales, Intune/GPO simples o equipos con salida normal a internet.
+
 Estas herramientas suelen correr los scripts como **SYSTEM**, y un cliente instalado así
 quedaría en el perfil de SYSTEM, donde nadie lo ve.
 
@@ -112,7 +166,8 @@ quedaría en el perfil de SYSTEM, donde nadie lo ve.
 | GPO | script de inicio de sesión en *User Configuration*, no de arranque en *Computer Configuration* |
 
 **Cuando no se puede** —*Run Scripts* de SCCM corre siempre como SYSTEM, igual que una
-Application con *Install for system*— el instalador lo detecta y no instala en SYSTEM:
+Application con *Install for system*, y un MSI siempre se instala con permisos de
+administrador— el instalador lo detecta y no instala en SYSTEM:
 
 1. busca al usuario con sesión iniciada (el dueño de `explorer.exe`);
 2. deja el instalador en el `%TEMP%` de ese usuario y lo corre con una tarea programada de
@@ -120,9 +175,10 @@ Application con *Install for system*— el instalador lo detecta y no instala en
 3. espera a que termine, muestra su salida y sale con su código;
 4. borra la tarea y la carpeta.
 
-El comando es el mismo en los dos casos. Las variables de entorno y los parámetros llegan
-a la sesión del usuario; la API key viaja como variable de entorno, nunca en una línea de
-comandos, y el script que la lleva se borra al arrancar.
+Lo hacen los tres: `install.ps1`, el paquete offline y el MSI. El comando es el mismo en
+los dos casos. Las variables de entorno y los parámetros llegan a la sesión del usuario; la
+API key viaja como variable de entorno, nunca en una línea de comandos, y el script que la
+lleva se borra al arrancar.
 
 ```powershell
 # el mismo script para todo el parque
@@ -141,9 +197,10 @@ Límites del camino por SYSTEM:
   *Only when a user is logged on*.
 - **Instala para el usuario con sesión**, el primero que encuentra. Otro usuario del mismo
   equipo es otro dispositivo y necesita su propia instalación.
-- ***Run Scripts* corta por timeout** (60 s por defecto) y la primera instalación tarda más
-  (baja electron). Si corta, la instalación sigue en la sesión del usuario, pero SCCM no
-  ve el resultado. Hay que subir el timeout.
+- ***Run Scripts* corta por timeout** (60 s por defecto). Para SCCM offline suba el
+  timeout a unos 1800 s porque baja y extrae un ZIP de alrededor de 150 MB. Si corta,
+  revise `C:\ProgramData\GlassNote\install-sccm-bootstrap.log` y
+  `C:\ProgramData\GlassNote\install-sccm.log`.
 - El `out.log` de la instalación queda tomado por el cliente, que hereda esa salida, hasta
   que se cierra. La carpeta `glassnote-install-*` se limpia en la siguiente instalación.
 
@@ -187,9 +244,11 @@ instalación la haya lanzado SYSTEM.
 - **Renderer**: a los 10 s de arrancar y después cada hora mira `version_renderer.txt` en el
   bucket de S3 y baja el zip a `%APPDATA%\glassnote\renderer`. No toca el binario.
 
-Salidas a internet que necesita el equipo: `registry.npmjs.org` (instalar y actualizar),
-`glassnote.s3.us-east-1.amazonaws.com` (renderer), `nodejs.org` (solo si no hay Node) y
-la API.
+Salidas a internet que necesita el equipo con el instalador genérico: `registry.npmjs.org`
+(instalar y actualizar), `glassnote.s3.us-east-1.amazonaws.com` (renderer), `nodejs.org`
+(solo si no hay Node) y la API. Con el instalador SCCM offline, la instalación inicial
+usa `glassnote.intermark.ec` para descargar el ZIP y la API para registrar el dispositivo;
+`registry.npmjs.org` queda para actualizaciones posteriores del cliente.
 
 Sin probar, pero a revisar con el área de sistemas del cliente:
 
@@ -240,7 +299,7 @@ días, lo que acota lo que se puede hacer con una que se filtre.
 Un equipo ya instalado se empareja sin reinstalar:
 
 ```sh
-glassnote pair --org-id 55 --api-key <clave> --device-name "Caja 01"
+glassnote pair --org-id <id> --api-key <clave> --device-name "Caja 01"
 ```
 
 Si el alta falla, el comando **sale con código distinto de cero** y dice por qué (la

package/autoStart.js

@@ -144,7 +144,7 @@ class AutoStart {
           
           fs.writeFileSync(tempScriptPath, script);
 
-          execSync(`cscript //nologo "${tempScriptPath}"`);
+          execSync(`cscript //nologo "${tempScriptPath}"`, { windowsHide: true });
 
           fs.unlinkSync(tempScriptPath);
 

package/bin/glassnote.js

@@ -72,7 +72,7 @@ function npmInvocation(args) {
 
 function runNpm(args, opts) {
 	const { file, args: argv, shell } = npmInvocation(args);
-	return spawnSync(file, argv, Object.assign({ stdio: 'inherit', shell, env: npmEnv() }, opts || {}));
+	return spawnSync(file, argv, Object.assign({ stdio: 'inherit', shell, env: npmEnv(), windowsHide: true }, opts || {}));
 }
 
 // userData tira de `uuid`, y este CLI corre también donde el árbol de dependencias no
@@ -113,6 +113,7 @@ function clienteEnMarcha() {
 		env: Object.assign({}, process.env, { ELECTRON_RUN_AS_NODE: '1' }),
 		stdio: 'ignore',
 		timeout: 4000,
+		windowsHide: true,
 	});
 	return res.status === 0;
 }
@@ -193,7 +194,7 @@ function cerrarClienteWindows() {
 	const res = spawnSync(
 		'powershell.exe',
 		['-NoProfile', '-NonInteractive', '-Command', guionCerrarCliente(rutaDelClienteInstalado(), process.pid)],
-		{ encoding: 'utf8', timeout: 20000 }
+		{ encoding: 'utf8', timeout: 20000, windowsHide: true }
 	);
 
 	// Si PowerShell no está o falló, no se sigue a ciegas: se mira si el cliente
@@ -272,12 +273,12 @@ function launch({ detach = false, extra = [] } = {}) {
 	}
 
 	if (detach) {
-		const child = spawn(binary, args, { detached: true, stdio: 'ignore', env });
+		const child = spawn(binary, args, { detached: true, stdio: 'ignore', env, windowsHide: true });
 		child.unref();
 		return 0;
 	}
 
-	const child = spawnSync(binary, args, { stdio: 'inherit', env });
+	const child = spawnSync(binary, args, { stdio: 'inherit', env, windowsHide: true });
 	if (child.error) fail(`no se pudo arrancar el cliente: ${child.error.message}`);
 	if (child.status !== 0 && process.platform === 'linux') {
 		console.error(
@@ -328,6 +329,7 @@ function addToPathWindows(dir = mode.BIN_DIR) {
 	].join('; ');
 	const res = spawnSync('powershell', ['-NoProfile', '-NonInteractive', '-Command', ps], {
 		encoding: 'utf8',
+		windowsHide: true,
 	});
 	const added = res.status === 0 && String(res.stdout).includes('added');
 	return { touched: added ? ['PATH de usuario (sin administrador)'] : [], line: dir };
@@ -389,6 +391,7 @@ function removeFromPathWindows() {
 	].join('; ');
 	const res = spawnSync('powershell', ['-NoProfile', '-NonInteractive', '-Command', ps], {
 		encoding: 'utf8',
+		windowsHide: true,
 	});
 	return res.status === 0 && String(res.stdout).includes('removed');
 }
@@ -633,10 +636,14 @@ async function cmdInstall(args) {
 	// Al arrancar, la app se registra sola en el autoarranque del usuario.
 	step('arrancando el cliente en segundo plano (queda en la bandeja del sistema)');
 	const binary = path.join(mode.INSTALLED_PACKAGE_DIR, 'bin', 'glassnote.js');
+	// windowsHide: en Windows un proceso desprendido abre su propia consola, y la gente la
+	// cierra. Lo mismo vale para cada spawn de este archivo: el ayudante de actualización
+	// corre sin consola, y ahí cualquier hijo de consola sin windowsHide abriría una.
 	const child = spawn(process.execPath, [binary, 'start', '--detach'], {
 		detached: true,
 		stdio: 'ignore',
 		env: process.env,
+		windowsHide: true,
 	});
 	child.unref();
 	log('Listo. Ícono en la bandeja; se abrirá solo en los próximos arranques.');

package/main.js

@@ -6,6 +6,7 @@ const {
 	Menu,
 	nativeImage,
 	screen,
+	session,
 } = require('electron');
 const packageJson = require('./package.json');
 const LocalServer = require('./localserver');
@@ -231,6 +232,8 @@ setInterval(cleanupOldLogs, LIMPIEZA_LOGS_MS).unref();
 createTailUtility(logsDir);
 
 app.whenReady().then(() => {
+	allowYoutubeEmbeds();
+
 	// macOS: esto es una app de bandeja, se maneja desde la barra de menu. Instalada por
 	// npm no hay .app propio, asi que el Dock mostraba el icono por defecto de Electron y
 	// una entrada que no sirve para nada. Se saca del Dock, pero antes se le pone el icono
@@ -865,23 +868,34 @@ function iniciarSondeoCursor() {
 		}
 		if (!dentro) return;
 
-		// De aca para abajo es solo de Linux. En Windows el `forward: true` de
-		// setIgnoreMouseEvents ya entrega los movimientos reales con la ventana ignorando
-		// el mouse —medido: el boton recibe mouseover y se puede clickear—, asi que
-		// inyectarlos seria duplicarlos.
-		if (!enLinux) return;
-
-		// Con el overlay ya clickeable los eventos reales llegan solos: inyectar seria
-		// duplicarlos.
-		if (!ignorandoMouse) return;
+		// En Linux se inyecta mientras el overlay ignora el mouse: ahi no llega nada, y con
+		// la ventana clickeable los eventos reales llegan solos.
+		//
+		// En Windows es AL REVES. Mientras ignora, el `forward: true` de setIgnoreMouseEvents
+		// ya entrega los movimientos reales —medido: el boton recibe mouseover y se puede
+		// clickear—. Pero con la ventana clickeable Windows NO le manda todos: el clic que
+		// activa el overlay (desde 2.4.12 se muestra sin foco, asi que el primer clic sobre
+		// un formulario lo activa) le devuelve el WS_EX_LAYERED a los ~30 ms, y una ventana
+		// layered deja pasar el mouse por sus pixeles transparentes a la ventana de abajo.
+		// El cursor sale del formulario, el renderer no recibe un solo movimiento, se queda
+		// con la ultima posicion —encima del formulario— y nunca devuelve el passthrough: el
+		// overlay queda clickeable y se come los clics sobre todo lo que dibuja. Medido en
+		// la VM de Windows 11 con el estilo de la ventana (0x80008 en vez de 0x80028) y con
+		// el estado del renderer; en 2.4.11, con la ventana ya activa, no pasaba.
+		// Se le cuenta la posicion desde aca y el renderer se pone al dia solo.
+		// En macOS no se midio nada de esto: queda como estaba.
+		if (process.platform === 'darwin') return;
+		if (enLinux ? !ignorandoMouse : ignorandoMouse) return;
 
 		// Repetir el mismo punto en cada tick es ruido, pero callarse del todo mientras el
 		// cursor esta quieto rompe el otro caso: el menu se abre DEBAJO de un cursor que no
 		// se movio, no hay mousemove que lo cuente, y ese boton nace muerto. Se reemite cada
 		// tanto para que la UI que aparece sola se entere igual.
+		// En Windows solo cuando el cursor se mueve: el menu que aparece bajo un cursor
+		// quieto ya lo cubre el forward, y repetir el punto no le cuenta nada nuevo.
 		const ahora = Date.now();
 		const mismoPunto = x === ultimoPuntoEnviado.x && y === ultimoPuntoEnviado.y;
-		if (mismoPunto && ahora - ultimoEnvioMs < REEMISION_QUIETO_MS) return;
+		if (mismoPunto && (!enLinux || ahora - ultimoEnvioMs < REEMISION_QUIETO_MS)) return;
 		ultimoPuntoEnviado = { x, y };
 		ultimoEnvioMs = ahora;
 		mainWindow.webContents.sendInputEvent({ type: 'mouseMove', x, y });
@@ -1057,6 +1071,41 @@ process.on('unhandledRejection', (reason, promise) => {
 
 
 
+/**
+ * YouTube rechaza el reproductor embebido que llega sin Referer: muestra "Video player
+ * configuration error" (el error 153) en vez del video. El renderer se carga desde file://
+ * y de ahi Chromium no manda Referer a ningun sitio https, asi que un glass con un video
+ * nunca lo reproduciria. Medido sobre Electron 29 con el mismo video: sin esto se queda en
+ * 0 s con el error; con esto reproduce, con sonido.
+ *
+ * Solo toca el pedido del reproductor (/embed/) y solo si no trae Referer: la
+ * previsualizacion web, que va por https, manda el suyo y no pasa por aca.
+ *
+ * OJO: Electron admite UN solo onBeforeSendHeaders por sesion. Registrar otro en cualquier
+ * lado reemplaza a este sin avisar, y los videos vuelven a dar el 153.
+ */
+function allowYoutubeEmbeds() {
+	try {
+		session.defaultSession.webRequest.onBeforeSendHeaders(
+			{
+				urls: [
+					'https://www.youtube.com/embed/*',
+					'https://www.youtube-nocookie.com/embed/*',
+				],
+			},
+			(details, callback) => {
+				const headers = details.requestHeaders;
+				if (!headers.Referer && !headers.referer) {
+					headers.Referer = 'https://glassnote.intermark.ec/';
+				}
+				callback({ requestHeaders: headers });
+			}
+		);
+	} catch (error) {
+		console.error('[youtube] no se pudo preparar el Referer de los videos:', error.message);
+	}
+}
+
 /**
  * Carga el HTML del renderer. Cual de las dos fuentes gana lo decide resolverRenderer()
  * en rendererPaths.js, que es tambien de donde sale la version que muestra el menu.

package/npmUpdate.js

@@ -238,12 +238,14 @@ class NpmUpdate {
 		}
 
 		try {
+			// windowsHide: sin él Windows le abre una consola al ayudante, que dura todo el
+			// npm install, y si el usuario la cierra la actualización muere a medias.
 			// cwd fuera del paquete: en Windows no se puede borrar un directorio que es
 			// el cwd de un proceso vivo, y ese proceso sería justamente el actualizador.
 			const child = spawn(
 				nodeBinary || process.execPath,
 				[cli, 'update', version, '--relaunch', '--wait', '4000'],
-				{ detached: true, stdio: ['ignore', salida, salida], env, cwd: os.tmpdir() }
+				{ detached: true, stdio: ['ignore', salida, salida], env, cwd: os.tmpdir(), windowsHide: true }
 			);
 			child.unref();
 			console.warn(`[update] ayudante lanzado, pid ${child.pid}; la app se cierra en 500 ms`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@glassnote/client",
-  "version": "2.4.16",
+  "version": "2.4.18",
   "description": "GlassNote — cliente de escritorio de notas superpuestas. Se instala con npx, sin instaladores nativos ni firmas.",
   "main": "main.js",
   "publishConfig": {
@@ -75,7 +75,7 @@
     "url": "git+ssh://git@intermarkec/intermarkec/glassnote-electron.git"
   },
   "dependencies": {
-    "@glassnote/renderer": "2.2.1",
+    "@glassnote/renderer": "2.3.2",
     "cors": "^2.8.5",
     "electron": "^29.4.6",
     "express": "^4.18.2",