Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/public/llms-full.txt
Original file line number Diff line number Diff line change
Expand Up @@ -4730,7 +4730,7 @@ Starts an OAuth 2.0 Device Authorization Grant (RFC 8628) against the Archgate p

Neither step is required. In CI, over SSH, or on a native Linux host with no display server (WSL reaches the Windows desktop) the CLI skips both and just prints them. Once authorized, the CLI hands the resulting tokens to git via `git credential approve`, so where they end up depends on the credential helper you have configured. A helper backed by your OS credential manager (macOS Keychain, Windows Credential Manager, Linux libsecret) keeps them encrypted; git's built-in `store` helper writes them to `~/.git-credentials` in plain text. Check yours with `git config --global credential.helper`.

Access tokens are short-lived. The CLI keeps a refresh token alongside them and renews the access token automatically, so signing in once is normally enough. If the refresh token itself expires or is revoked, the CLI reports that the session has expired, and `archgate login` re-establishes it. A token issued before this flow existed keeps working only until you sign in to the platform; from then on the platform session alone decides.
Signing in once is normally enough: the CLI keeps your session current on its own. If the session expires or is revoked, the CLI treats you as signed out, and `archgate login` signs you in again.

Signing in also registers `archgate credential` as a git credential helper for `plugins.archgate.dev`, which is what lets `git clone` of a plugin repository authenticate without prompting. See [`archgate credential`](/reference/cli/credential/).

Expand Down
2 changes: 1 addition & 1 deletion docs/src/content/docs/nb/reference/cli/login.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Starter en OAuth 2.0 Device Authorization Grant (RFC 8628) mot Archgate-plattfor

Ingen av delene er påkrevd. I CI, over SSH eller på en ren Linux-maskin uten skjermserver (WSL når Windows-skrivebordet) hopper CLI-en over begge og skriver dem bare ut. Når autorisasjonen er fullført, gir CLI-en tokenene til git via `git credential approve`, så hvor de havner avhenger av hvilken credential-helper du har konfigurert. En helper som bruker operativsystemets legitimasjonsbehandler (macOS Keychain, Windows Credential Manager, Linux libsecret) holder dem krypterte; gits innebygde `store`-helper skriver dem til `~/.git-credentials` i klartekst. Sjekk din med `git config --global credential.helper`.

Tilgangstokener er kortlivede. CLI-en beholder et refresh-token ved siden av dem og fornyer tilgangstokenet automatisk, så det holder normalt å logge inn én gang. Hvis selve refresh-tokenet utløper eller blir tilbakekalt, melder CLI-en at økten er utløpt, og `archgate login` gjenoppretter den. Et token utstedt før denne flyten fantes virker bare til du logger inn på plattformen; fra da av er det plattformøkten alene som gjelder.
Det holder normalt å logge inn én gang: CLI-en holder økten din oppdatert av seg selv. Hvis økten utløper eller blir tilbakekalt, behandler CLI-en deg som utlogget, og `archgate login` logger deg inn igjen.

Innlogging registrerer også `archgate credential` som en git credential helper for `plugins.archgate.dev`, som er det som lar `git clone` av et plugin-repositorium autentisere uten å spørre. Se [`archgate credential`](/reference/cli/credential/).

Expand Down
2 changes: 1 addition & 1 deletion docs/src/content/docs/pt-br/reference/cli/login.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Inicia um OAuth 2.0 Device Authorization Grant (RFC 8628) na plataforma Archgate

Nenhuma das duas etapas é obrigatória. Em CI, via SSH ou em uma máquina Linux nativa sem servidor gráfico (o WSL alcança a área de trabalho do Windows), a CLI pula ambas e apenas os exibe. Após a autorização, a CLI entrega os tokens ao git via `git credential approve`, então onde eles ficam depende do credential helper que você tem configurado. Um helper apoiado no gerenciador de credenciais do sistema operacional (macOS Keychain, Windows Credential Manager, libsecret no Linux) os mantém criptografados; o helper `store` embutido do git os grava em `~/.git-credentials` em texto puro. Verifique o seu com `git config --global credential.helper`.

Os tokens de acesso têm vida curta. A CLI mantém um refresh token junto deles e renova o token de acesso automaticamente, então normalmente basta entrar uma vez. Se o próprio refresh token expirar ou for revogado, a CLI informa que a sessão expirou, e o `archgate login` a restabelece. Um token emitido antes deste fluxo existir continua funcionando apenas até você entrar na plataforma; a partir daí, somente a sessão da plataforma decide.
Normalmente basta entrar uma vez: a CLI mantém sua sessão atualizada sozinha. Se a sessão expirar ou for revogada, a CLI considera você desconectado, e o `archgate login` faz seu login novamente.

Entrar também registra `archgate credential` como um credential helper do git para `plugins.archgate.dev`, que é o que permite ao `git clone` de um repositório de plugin autenticar sem solicitar credenciais. Veja [`archgate credential`](/reference/cli/credential/).

Expand Down
2 changes: 1 addition & 1 deletion docs/src/content/docs/reference/cli/login.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Starts an OAuth 2.0 Device Authorization Grant (RFC 8628) against the Archgate p

Neither step is required. In CI, over SSH, or on a native Linux host with no display server (WSL reaches the Windows desktop) the CLI skips both and just prints them. Once authorized, the CLI hands the resulting tokens to git via `git credential approve`, so where they end up depends on the credential helper you have configured. A helper backed by your OS credential manager (macOS Keychain, Windows Credential Manager, Linux libsecret) keeps them encrypted; git's built-in `store` helper writes them to `~/.git-credentials` in plain text. Check yours with `git config --global credential.helper`.

Access tokens are short-lived. The CLI keeps a refresh token alongside them and renews the access token automatically, so signing in once is normally enough. If the refresh token itself expires or is revoked, the CLI reports that the session has expired, and `archgate login` re-establishes it. A token issued before this flow existed keeps working only until you sign in to the platform; from then on the platform session alone decides.
Signing in once is normally enough: the CLI keeps your session current on its own. If the session expires or is revoked, the CLI treats you as signed out, and `archgate login` signs you in again.

Signing in also registers `archgate credential` as a git credential helper for `plugins.archgate.dev`, which is what lets `git clone` of a plugin repository authenticate without prompting. See [`archgate credential`](/reference/cli/credential/).

Expand Down
2 changes: 1 addition & 1 deletion src/helpers/sentry.ts
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ const SENTRY_DSN =
* Sentry tunnel — routes envelopes through our own domain instead of
* hitting ingest.de.sentry.io directly. Better reputation with corporate
* proxies and ad-blockers, matching the PostHog proxy at n.archgate.dev.
* The tunnel server lives in services/sentry-tunnel/ and runs on Railway.
* The tunnel server is services/sentry-tunnel/ in archgate/services.
*/
const SENTRY_TUNNEL = "https://s.archgate.dev/tunnel";

Expand Down
Loading