Connecting a GitLab account

GitLab connects the same way GitHub does — OAuth with PKCE in your default browser, tokens in the macOS Keychain — with two differences worth knowing.

No client secret

The GitLab flow uses no client secret. PKCE is what proves the request came from the application that started it, which is the right design for a desktop app, where a secret compiled into the binary is not a secret.

Self-hosted and Dedicated instances

GitLab installations of your own are fully supported: both OAuth and the API work. You configure the application for your instance and Innesta indexes the configuration by full base URL, so several instances can be connected at once and each keeps its own.

Registering it and filling in the two fields afterwards is a page of its own: self-hosted GitLab and GitHub Enterprise Server.

Refreshing

GitLab’s OAuth sessions expire. Innesta refreshes one before a request when at most

min(5 minutes, max(30 seconds, 10% of the token lifetime))

of its lifetime remains. Short-lived tokens are refreshed proportionally, long-lived ones get a five-minute margin, and nothing is refreshed on a token that has hours left.

There is no background timer. Refreshing happens when a request is about to be made, which is the only moment a valid token is actually needed — a timer would wake the app up to renew credentials for a session you are not using.

The first 401 is kept as a fallback: it triggers one refresh and one replay of the request. That applies to any session, and it is what covers a session migrated from an older version of Innesta, which has no recorded expiry and so nothing to work out in advance.