Connecting to Git: app guide

For whoever administers the organization on GitHub or the group on GitLab. It is done once and serves the whole team.

Versiona writes the load script to your company's Git, under the name of whoever changed it. For that, each person needs to connect to Git through the extension. There are two ways, and the recommended one is the app.

	With an app, recommended	With a personal token
Who sets it up	The organization's administrator, once	Each person, their own
How the person signs in	With their own Git account	Creates a token, copies it and pastes it into the extension
What it reaches	Only the repositories the administrator chose	Whatever each person selects when creating the token
To cut off access	The administrator revokes everyone's at once	Each person revokes their own
Expiration	Handled by the app	The token expires, and the extension warns 15 days in advance

Either way, the token stays only in each person's browser and goes only to your company's Git. Cubotimize receives no token, no script and no data at all, and the extension does not use the app's "secret": it does not need to be generated. See the privacy policy.

GitHub: create the GitHub App

It has to be a GitHub App, not an OAuth App: a GitHub App only sees the repositories it is installed on. An OAuth App would reach every private repository of each person.

In the organization, open Settings, Developer settings, GitHub Apps, New GitHub App.
GitHub App name: a name the team will recognize, for example "Versiona" followed by the company name.
Homepage URL and Callback URL: GitHub requires both, and the Versiona login uses neither. You can use the address of the organization itself on GitHub.
Check Enable Device Flow. This is the login by code, which Versiona uses.
Leave Expire user authorization tokens checked. The token then lasts 8 hours, and Versiona renews it by itself, from v1.13.0 on. A stolen token stops being valid forever.
Under Webhook, uncheck Active. Versiona does not use it, and if checked GitHub requires an address.
Under Repository permissions, grant Contents: Read and write. "Metadata: Read-only" is added automatically. Everything else stays at "No access".
Under "Where can this GitHub App be installed?", leave Only on this account.
Click Create GitHub App.

Check, copy the Client ID and install

Under Optional features, the "User-to-server token expiration" row should show the Opt-out button. That means the 8-hour expiration is on. If it shows "Opt-in", click it.
Under General, copy the Client ID, which starts with Iv. It is not the "App ID", which is only digits.
Do not generate a "client secret" or a "private key": Versiona uses neither. The yellow notice asking for the key can be ignored.
Under Install App, install it on the organization with Only select repositories, selecting only the scripts repository.

The installation screen should show two permissions and no others: "Read access to metadata" and "Read and write access to code".

In the extension

In the server setup, choose GitHub and paste the Client ID into "Client ID of the app".
Enter the repository address and save.
When connecting, the extension shows a code. Each person types that code at github.com/login/device, with their own account, and authorizes.

Each person only reaches what their account already reaches: someone without write permission on the repository still cannot write.

GitLab: create the Application

In the group, open Settings, Applications. Someone who does not administer the group has the same form under Edit profile, Applications, and the instance administrator has it in the admin area.
Redirect URI: the address the extension shows in the server setup, under "How to get the Application ID", with the copy button. For the extension installed from the Chrome Web Store, it is:
```
https://fhfhemfocaiigoakdnbafeoeibgemfag.chromiumapp.org/gitlab
```
Uncheck Confidential. The extension does not keep a secret.
Select only the api scope.
Save and copy the Application ID. The "Secret" is not used.

In the extension, choose GitLab in the server setup and paste the Application ID. Each person signs in with their own GitLab login, and the extension renews the access by itself.

Do you also want automatic versioning overnight? See the nightly routine guide.

Without an app: personal token

Security recommendation. The personal token is the least protected option: each person chooses the scope and the expiration of their own, and it stays valid until it expires. If you use one, create it just for Versiona, with only the scripts repository, only the permission to write to it and an expiration of 90 days or less. Do not reuse a token from another purpose. The extension shows this same warning to whoever chooses the token.

It works, and it suits someone who uses Versiona alone or wants to try it before involving the administrator. Leave the app field blank in the setup, and each person creates their own token:

GitHub: a "fine-grained" token, under Settings, Developer settings, Personal access tokens. Only the scripts repository, with Contents set to read and write, and an expiration date.
GitLab: under Edit profile, Access tokens, with the api scope and an expiration date. The role in the project must be Developer.

Copy the token straight into the extension. Do not paste it into an email, a ticket or a chat.
Always use an expiration date. The extension warns 15 days before it expires.

The repository

It has to be private. Versiona refuses to write to a public repository.
A load script may contain business rules, table names and connection details: control who has access to the repository.
One repository can hold more than one Qlik environment, each in its own folder. The folder is chosen in the server setup.

For IT: distributing by policy (GPO)

Versiona reads a browser policy, which IT distributes by GPO, Intune or the registry. With it, nobody needs to set up a server: the person installs the extension (or receives it installed) and only connects to Git with their own account. It is also how the company enforces the security rules.

servidores: the list of Qlik servers and the repository of each one, already with the Application ID or the Client ID. A server that comes from the policy cannot be edited by the user, and counts as the organization's confirmation of the responsibility statement.
exigir_aplicativo: with true, nobody connects with a personal token. Only through the app sign-in.
exigir_trava: with true, the extension only connects and only uses the token after the person turns on the PIN or biometrics, and the screen does not offer to turn it off. Windows Hello, a security key or the phone will do.
itens_mestres: with true, every server also versions the app's master items and variables; with false, none does. Without the key, each server keeps its own choice.

The example below is a .reg file for Chrome. It installs the extension for everyone, requires the app and registers one server. Replace the addresses, the Application ID and the project with yours. In Edge, the path starts with SOFTWARE\Policies\Microsoft\Edge instead of 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}]"

In servidores, the value is a text holding the list in JSON. The fields are the ones of the server setup: nome (name), hosts_qlik, provedor (gitlab or github), origem_git (always with https://), application_id, projeto (project), branch, pasta (folder), rotina_noturna (nightly routine) and itens_mestres (true to also version master items and variables).
If the company already uses the forced installation list, do not reuse the number "1": use the next free one.
No field is a secret. Do not put a token or a password in the policy: there is no field for that.
To check, open chrome://policy (or edge://policy) on the user's machine: the policy appears in the Versiona CuboPlus section.
The first time on each Qlik server, the person still authorizes the extension to read that address. The browser asks them for that, and the policy does not replace it.

Protect the token with PIN or biometrics (highly recommended)

From v1.17.0 on, Versiona can require Windows Hello to use the Git token. With it on, the token only opens on this computer, after you confirm with your PIN or biometrics. Malware that copies the browser profile takes a token that opens nowhere. We highly recommend turning it on on every computer with Windows Hello set up. Without Windows Hello, a security key (USB) or your phone will do, from v1.21.0 on. The security key is still experimental.

Click the Versiona icon and open Servers.
At the bottom of the screen, under "Require PIN or biometrics to use the token", click Turn on.
Choose where the passkey is kept: Windows Hello (recommended), Security key (USB) or Phone.
With Windows Hello, the Windows Security window appears saying "This will be saved to your Windows device": that is Windows Hello, and the passkey stays only on this computer. If the browser offers Google Password Manager before it, choose Save another way and then Windows Hello.
Confirm with your PIN or biometrics. Windows asks twice when turning it on: once to create the passkey, once to use it.

Day to day, the PIN or biometrics is requested once each time the browser is opened. When you enter Qlik, the mascot asks, and one click on "Unlock" is enough.
"Lock now", on the same screen, locks the token right away, for when you step away from the computer.
Three places work. Windows Hello, which ties the passkey to this computer; a FIDO2 security key with a PIN or fingerprint, which must be plugged in when unlocking; and your phone, with Bluetooth on on both devices.
On the phone, the passkey must go to the native vault: Google Password Manager on Android, or Apple Passwords on iPhone. A password vault from another vendor will not do: turning it on is refused, without changing anything. The passkey follows the Google or Apple account, and the guarantee then depends on it: use an account different from the one signed in to the computer's browser. With the same account, the passkey is within reach of the browser itself. Tested on Android; not yet on iPhone.
A passkey kept in the browser's Google account is refused, and nothing changes: it lives in the same profile the protection is meant to guard.
It does not protect against everything: a program running in your session after the unlock can still reach the token. That is why the measures on the Git side, right below, still apply.
Lost access to Windows Hello, the security key or the phone? Use "I lost access: delete the connections and turn off", and connect to Git again.

What it needs: Windows Hello set up on this computer (PIN, fingerprint or face), or a security key, or your phone, and a current Chrome. Windows Hello was tested in Chrome on Windows 11; the security key and the phone were not yet. If the computer does not have what the feature needs, turning it on is refused, nothing is changed, and the screen says why.

If the token is stolen: what your Git host can block

The token Versiona uses stays in each person's browser. Since v1.12.0 it is written to disk encrypted, with a key created in that browser profile that cannot be exported. This keeps the token out of reach of common malware that sweeps the browser for plain-text credentials.

It is not a guarantee: someone who copies the whole browser profile, or has a program running in the person's session, can still get to the token. What stops a stolen token from working elsewhere is the configuration of the Git host, and that depends on the plan. The tables below show what each plan offers.

GitHub

Protection	Free	Pro	Team	Enterprise Cloud	Enterprise Server
IP allow listblocks the token outside the company network	no	no	no	yes	no
Conditional access through the identity providerchecks the IP on each use; only with managed users and Microsoft Entra ID	no	no	no	yes	no
Protected branch on a private repositorythe stolen token cannot delete the branch or rewrite history	no	yes	yes	yes	yes
Rules for personal access tokensapproval by the organization owner and maximum lifetime	not confirmed	does not apply	not confirmed	yes	yes
Audit log with the IP of whoever used ithelps to discover misuse, not to prevent it	no	no	no	yes	not confirmed
Revoke the accessthe person revokes the app in their own account settings	yes	yes	yes	yes	yes

GitLab

Protection	Free (GitLab.com)	Premium	Ultimate	Self-managed, no paid license
GitLab only on the internal network or VPNblocks the token outside the network; it is network configuration, not a GitLab feature	does not apply	yes	yes	yes
Group access restricted by IPblocks the token outside the listed IPs, including through the API	no	yes	yes	no
The token from the application sign-in lasts 2 hoursand the refresh token is replaced on each use	yes	yes	yes	yes
Mandatory expiration on new tokensup to 365 days by default	yes	yes	yes	yes
Protected branchno force push; deleting through the API still depends on the person's role	yes	yes	yes	yes
Last IPs that used the token, and revokingthe person sees and revokes; the administrator revokes through the API	yes	yes	yes	yes
Audit of token usehelps to discover, not to prevent	no	yes	yes	no
Credentials inventorythe administrator lists and revokes everyone's tokens	no	no	yes	no

Checked in the official documentation on October 6, 2026: GitHub.com and GitHub Enterprise Cloud (no version number), GitHub Enterprise Server 3.22, GitLab 19.5. Plans change: check the link in each row before deciding. "Not confirmed" means the documentation we read does not say on which plan the feature exists.

What to do, in order of effect

Restrict the network. It is the only measure that stops the token from working elsewhere. On a self-managed GitLab, make it reachable only from the internal network or the VPN: this works on any license. On GitLab.com, IP restriction requires the Premium plan. On GitHub, the IP allow list requires Enterprise Cloud.
Require PIN or biometrics in the extension. It is what stops the token from opening outside the person's computer, on any Git plan. See how to turn it on.
Encrypt the computer's disk. On Windows Pro and Enterprise that is BitLocker; on Home, "Device encryption". It covers the lost or stolen laptop and the disk taken out of the machine: without it, whoever has the disk reads the whole browser profile. It does not protect against a program running in the person's session. IT usually turns it on, and also keeps the recovery key.
Use the app, not a personal token. With the GitHub App, access reaches only the repositories chosen at installation. With expiration on, its token lasts 8 hours. With the GitLab Application, the token lasts 2 hours.
Grant the minimum scope. One repository just for the scripts, and each person with only the role they need to write to it.
Protect the branch. No force push and no deletion: a stolen token can write, but it cannot destroy the history. On GitHub, a protected private repository requires Pro or Team.
Know how to revoke. If in doubt, revoke: the person removes the authorized app in their own account and connects again through Versiona.

What does not block a token that was already stolen: two-factor authentication, which protects the sign-in and not the token (GitLab says so); the IP allow list of the GitHub App itself, which applies to the app and not to the person's token; and GitLab's certificate or smart card sign-in, which the documentation describes for access through the screen, not through the API.

If something goes wrong

What you see	What it usually is
The extension says "Enable Device Flow" is missing	The option was left unchecked in the GitHub App. Check it under General and save.
It connects, but does not find the repository	The GitHub App was not installed on the organization, or the repository was not selected in the installation.
It asks to connect again every day	The extension is older than v1.13.0, which did not renew the GitHub token. Update the extension and connect again once.
GitLab rejects the redirect address	The Application's Redirect URI is different from the one the extension shows in the setup.
It reads, but does not write	The person's account has no write access to the repository, or the branch is protected and only accepts Maintainers.

Questions, suggestions or problems: [email protected]. Do not send tokens, passwords or load scripts by email.

Install Versiona CuboPlus