Conectar a Git: guía de la aplicación

Para quien administra la organización en GitHub o el grupo en GitLab. Se hace una sola vez y sirve a todo el equipo.

Versiona graba el script de carga en el Git de su empresa, con el nombre de quien lo modificó. Para eso, cada persona necesita conectarse a Git desde la extensión. Hay dos maneras, y la recomendada es la aplicación.

En las dos maneras, el token queda solo en el navegador de cada persona y va solo al Git de su empresa. Cubotimize no recibe ningún token, script ni dato, y la extensión no usa el "secreto" de la aplicación: no hace falta generarlo. Vea la política de privacidad.

GitHub: crear la GitHub App

Tiene que ser una GitHub App, y no una OAuth App: la GitHub App solo ve los repositorios en los que se instala. La OAuth App alcanzaría todos los repositorios privados de cada persona.

1. En la organización, abra Settings, Developer settings, GitHub Apps, New GitHub App.
2. GitHub App name: un nombre que el equipo reconozca, por ejemplo "Versiona" seguido del nombre de la empresa.
3. Homepage URL y Callback URL: GitHub exige los dos, y el login de Versiona no usa ninguno. Se puede usar la dirección de la propia organización en GitHub.
4. Marque Enable Device Flow. Es el login por código, que Versiona usa.
5. Deje marcado Expire user authorization tokens. El token pasa a durar 8 horas, y Versiona lo renueva solo, desde la v1.13.0. Un token robado deja de valer para siempre.
6. En Webhook, desmarque Active. Versiona no lo usa, y si queda marcado GitHub exige una dirección.
7. En Repository permissions, otorgue Contents: Read and write. "Metadata: Read-only" se agrega solo. Todo lo demás queda en "No access".
8. En "Where can this GitHub App be installed?", deje Only on this account.
9. Haga clic en Create GitHub App.

Verificar, copiar el Client ID e instalar

1. En Optional features, la línea "User-to-server token expiration" debe mostrar el botón Opt-out. Es señal de que la vigencia de 8 horas está activada. Si muestra "Opt-in", haga clic en él.
2. En General, copie el Client ID, que empieza con Iv. No es el "App ID", que es solo un número.
3. No genere "client secret" ni "private key": Versiona no usa ninguno de los dos. El aviso amarillo que pide la clave se puede ignorar.
4. En Install App, instale en la organización con Only select repositories, marcando solo el repositorio de los scripts.

La pantalla de instalación debe mostrar dos permisos y ninguno más: "Read access to metadata" y "Read and write access to code".

En la extensión

1. En el registro del servidor, elija GitHub y pegue el Client ID en "Client ID de la aplicación".
2. Indique la dirección del repositorio y guarde.
3. Al conectar, la extensión muestra un código. Cada persona escribe ese código en github.com/login/device, con su propia cuenta, y autoriza.

Cada persona solo alcanza lo que su cuenta ya alcanza: quien no tiene permiso de escritura en el repositorio sigue sin poder grabar.

GitLab: crear la Application

1. En el grupo, abra Settings, Applications. Quien no administra el grupo tiene el mismo formulario en Edit profile, Applications, y el administrador de la instancia, en el área de administración.
2. Redirect URI: la dirección que la extensión muestra en el registro del servidor, en "Cómo obtener el Application ID", con el botón de copiar. Para la extensión instalada desde la Chrome Web Store, es:

   https://fhfhemfocaiigoakdnbafeoeibgemfag.chromiumapp.org/gitlab

3. Desmarque Confidential. La extensión no guarda ningún secreto.
4. Marque solo el alcance api.
5. Guarde y copie el Application ID. El "Secret" no se usa.

En la extensión, elija GitLab en el registro del servidor y pegue el Application ID. Cada persona entra con su propio login de GitLab, y la extensión renueva el acceso sola.

¿Quiere también el versionado automático de madrugada? Vea la guía de la rutina nocturna.

Sin aplicación: token personal

Recomendación de seguridad. El token personal es la opción de menor protección: cada persona elige el alcance y la vigencia del suyo, y sigue valiendo hasta que vence. Si va a usarlo, cree uno solo para Versiona, con únicamente el repositorio de los scripts, únicamente el permiso de escribir en él y una vigencia de 90 días o menos. No reutilice un token de otro uso. La extensión muestra este mismo aviso a quien elige el token.

Funciona, y sirve para quien lo usa solo o quiere probar antes de involucrar al administrador. Deje el campo de la aplicación en blanco en el registro, y cada persona crea su token:

• GitHub: token "fine-grained", en Settings, Developer settings, Personal access tokens. Solo el repositorio de los scripts, con Contents de lectura y escritura, y una fecha de vencimiento.
• GitLab: en Edit profile, Access tokens, con el alcance api y una fecha de vencimiento. El rol en el proyecto tiene que ser Developer.

• Copie el token directo a la extensión. No lo pegue en un correo, un ticket ni un chat.
• Use siempre una fecha de vencimiento. La extensión avisa 15 días antes de que venza.

El repositorio

• Tiene que ser privado. Versiona se niega a grabar en un repositorio público.
• El script de carga puede contener reglas de negocio, nombres de tablas y datos de conexión: controle quién tiene acceso al repositorio.
• Un repositorio puede guardar más de un entorno Qlik, cada uno en su carpeta. La carpeta se elige en el registro del servidor.

Para TI: distribuir por política (GPO)

Versiona lee una política del navegador, que TI distribuye por GPO, Intune o el registro. Con ella, nadie necesita registrar un servidor: la persona instala la extensión (o la recibe instalada) y solo se conecta a Git con su propia cuenta. También es por donde la empresa impone las reglas de seguridad.

• servidores: la lista de servidores Qlik y el repositorio de cada uno, ya con el Application ID o el Client ID. Un servidor que viene de la política no puede ser editado por quien lo usa, y vale como la confirmación de la declaración de responsabilidad por la organización.
• exigir_aplicativo: con true, nadie se conecta con un token personal. Solo por el inicio de sesión de la aplicación.
• exigir_trava: con true, la extensión solo se conecta y solo usa el token después de que la persona active el PIN o la biometría, y la pantalla no ofrece desactivarlo. Sirven Windows Hello, una llave de seguridad o el celular.
• itens_mestres: con true, todos los servidores versionan también los elementos maestros y las variables de la app; con false, ninguno. Sin la clave, vale la elección de cada servidor.

El ejemplo de abajo es un archivo .reg para Chrome. Instala la extensión para todos, exige la aplicación y registra un servidor. Cambie las direcciones, el Application ID y el proyecto por los suyos. En Edge, la ruta empieza con SOFTWARE\Policies\Microsoft\Edge en lugar de SOFTWARE\Policies\Google\Chrome.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist]
"1"="fhfhemfocaiigoakdnbafeoeibgemfag;https://clients2.google.com/service/update2/crx"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\fhfhemfocaiigoakdnbafeoeibgemfag\policy]
"exigir_aplicativo"=dword:00000001
"exigir_trava"=dword:00000001
"itens_mestres"=dword:00000001
"servidores"="[{\"nome\":\"Qlik\",\"hosts_qlik\":[\"qlik.example.com\"],\"provedor\":\"gitlab\",\"origem_git\":\"https://git.example.com\",\"application_id\":\"APPLICATION_ID\",\"projeto\":\"grupo/scripts-qlik\",\"rotina_noturna\":false}]"

• En servidores, el valor es un texto con la lista en JSON. Los campos son los del registro del servidor: nome (nombre), hosts_qlik, provedor (gitlab o github), origem_git (siempre con https://), application_id, projeto (proyecto), branch, pasta (carpeta), rotina_noturna (rutina nocturna) e itens_mestres (true para versionar también los elementos maestros y las variables).
• Si la empresa ya usa la lista de instalación forzada, no reutilice el número "1": use el siguiente libre.
• Ningún campo es secreto. No ponga un token ni una contraseña en la política: no existe un campo para eso.
• Para verificar, abra chrome://policy (o edge://policy) en el equipo de quien la usa: la política aparece en la parte de Versiona CuboPlus.
• La primera vez en cada servidor Qlik, la persona todavía autoriza a la extensión a leer esa dirección. Eso se lo pide el navegador, y la política no lo reemplaza.

Proteger el token con PIN o biometría (muy recomendado)

Desde la v1.17.0, Versiona puede exigir Windows Hello para usar el token de Git. Con eso activado, el token solo se abre en esta computadora, después de que usted confirme con su PIN o biometría. Un programa malicioso que copie el perfil del navegador se lleva un token que no se abre en ningún lugar. Recomendamos mucho activarlo en toda computadora con Windows Hello configurado. Sin Windows Hello, sirven una llave de seguridad (USB) o el celular, desde la v1.21.0. La llave de seguridad todavía es experimental.

1. Haga clic en el ícono de Versiona y abra Servidores.
2. Al final de la pantalla, en "Exigir PIN o biometría para usar el token", haga clic en Activar.
3. Elija dónde queda la llave de acceso: Windows Hello (recomendado), Llave de seguridad (USB) o Celular.
4. En Windows Hello, aparece la ventana Seguridad de Windows diciendo "Esto se guardará en su dispositivo Windows": es Windows Hello, y la llave queda solo en esta computadora. Si antes el navegador ofrece el Administrador de contraseñas de Google, elija Guardar de otra forma y luego Windows Hello.
5. Confirme con su PIN o biometría. Windows lo pide dos veces en la activación: una para crear la llave de acceso, otra para usarla.

• En el día a día, el PIN o la biometría se pide una vez cada vez que se abre el navegador. Al entrar en Qlik, la mascota pregunta, y un clic en "Desbloquear" basta.
• "Bloquear ahora", en la misma pantalla, bloquea el token en el momento, para cuando usted se aleje de la computadora.
• Sirven tres lugares. Windows Hello, que ata la llave a esta computadora; una llave de seguridad FIDO2 con PIN o huella, que debe estar conectada al desbloquear; y el celular, con el Bluetooth activado en los dos equipos.
• En el celular, la llave debe ir al cofre nativo: el Administrador de contraseñas de Google en Android, o Contraseñas de Apple en iPhone. Un cofre de contraseñas de otro fabricante no sirve: la activación se rechaza, sin cambiar nada. La llave acompaña a la cuenta de Google o Apple, y la garantía pasa a depender de ella: use una cuenta distinta de la que tiene la sesión iniciada en el navegador de la computadora. Con la misma cuenta, la llave queda al alcance del propio navegador. Probado en Android; en iPhone, todavía no.
• La llave guardada en la cuenta de Google del navegador se rechaza, y nada cambia: vive en el mismo perfil que la protección quiere cuidar.
• No protege de todo: un programa que se ejecute en su sesión después del desbloqueo todavía alcanza el token. Por eso las medidas del lado de Git, justo abajo, siguen valiendo.
• ¿Perdió el acceso a Windows Hello, a la llave de seguridad o al celular? Use "Perdí el acceso: borrar las conexiones y desactivar", y conéctese de nuevo a Git.

Qué necesita: Windows Hello configurado en esta computadora (PIN, huella o rostro), o una llave de seguridad, o el celular, y un Chrome actual. Windows Hello se probó en Chrome con Windows 11; la llave de seguridad y el celular todavía no. Si la computadora no tiene lo que la función necesita, la activación se rechaza, no se cambia nada, y la pantalla dice el motivo.

Si roban el token: qué puede bloquear su Git

El token que usa Versiona queda en el navegador de cada persona. Desde la v1.12.0 se guarda en el disco cifrado, con una clave creada en ese perfil del navegador y que no se puede exportar. Eso lo deja fuera del alcance del programa malicioso común, que recorre el navegador en busca de credenciales en texto.

No es una garantía: quien copie el perfil completo del navegador, o tenga un programa ejecutándose en la sesión de la persona, todavía puede llegar al token. Lo que impide que un token robado funcione en otro lugar es la configuración del Git, y depende del plan. Las tablas de abajo muestran qué ofrece cada plan.

GitHub

GitLab

Consultado en la documentación oficial el 6 de octubre de 2026: GitHub.com y GitHub Enterprise Cloud (sin número de versión), GitHub Enterprise Server 3.22, GitLab 19.5. Los planes cambian: revise el enlace de cada fila antes de decidir. "No confirmado" significa que la documentación leída no dice en qué plan existe la función.

Qué hacer, por orden de efecto

1. Restringir la red. Es la única medida que impide que el token funcione en otro lugar. En el GitLab instalado en la empresa, déjelo accesible solo por la red interna o por la VPN: funciona con cualquier licencia. En GitLab.com, la restricción por IP requiere el plan Premium. En GitHub, la lista de IP requiere Enterprise Cloud.
2. Exigir PIN o biometría en la extensión. Es lo que impide que el token se abra fuera de la computadora de la persona, en cualquier plan de Git. Vea cómo activarlo.
3. Cifrar el disco de la computadora. En Windows Pro y Enterprise es BitLocker; en Home, el "Cifrado del dispositivo". Cubre el caso de la notebook perdida o robada y del disco retirado del equipo: sin eso, quien tiene el disco lee todo el perfil del navegador. No protege de un programa que se ejecute en la sesión de la persona. Normalmente lo activa TI, que también guarda la clave de recuperación.
4. Usar la aplicación, y no el token personal. Con la GitHub App, el acceso alcanza solo los repositorios elegidos en la instalación. Con la vigencia activada, su token dura 8 horas. Con la Application de GitLab, el token dura 2 horas.
5. Dar el alcance mínimo. Un repositorio solo para los scripts, y cada persona solo con el rol que necesita para escribir en él.
6. Proteger la branch. Sin push forzado y sin borrado: un token robado puede escribir, pero no destruye el historial. En GitHub, un repositorio privado protegido requiere Pro o Team.
7. Saber revocar. Ante la sospecha, revoque: la persona quita la aplicación autorizada en su propia cuenta y se conecta de nuevo desde Versiona.

Lo que no bloquea un token ya robado: la verificación en dos pasos, que protege el inicio de sesión y no el token (GitLab lo dice); la lista de IP de la propia GitHub App, que vale para la aplicación y no para el token de la persona; y el inicio de sesión con certificado o tarjeta inteligente de GitLab, que la documentación describe para el acceso por pantalla, y no por la API.

Si algo sale mal

Dudas, sugerencias o problemas: [email protected]. No envíe tokens, contraseñas ni scripts de carga por correo electrónico.

Instalar Versiona CuboPlus