Documentation
¶
Overview ¶
Package auth obtains API tokens by delegating entirely to the glab and gh CLIs. gu never reads a credential file and never performs an OAuth flow: the user's only setup step is `glab auth login` / `gh auth login`.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type Host ¶
Host is one authenticated endpoint for one profile.
type RefreshTransport ¶ added in v0.15.0
type RefreshTransport struct {
Source *Source
Next http.RoundTripper
}
RefreshTransport keeps a session working across a token's expiry.
It stamps the Source's current token on every request, so once a token has been renewed every later request carries the new one without the client being rebuilt. And when a request comes back 401 — the token lapsed while it was in flight — it asks the Source for a fresh one and replays the request once, so the expiry costs a round trip rather than an error on screen.
Both SDKs set their own Authorization header from the token they were built with, which is a value fixed at construction. Stamping here is what makes that value a starting point rather than a life sentence.
type Source ¶ added in v0.15.0
type Source struct {
// contains filtered or unexported fields
}
Source hands out the API token for one profile and host, and can be told the one it holds has stopped working.
It exists because a token is not necessarily good for as long as gu runs. `glab auth login`'s web flow leaves an OAuth access token, which GitLab expires after a couple of hours; glab renews it from the refresh token kept beside it. gu takes no part in that — it holds no client secret and runs no OAuth flow, as this package's doc comment says. "Refreshing" here means asking glab a second time and trusting it to have done the renewing.
A Source is safe for concurrent use, and asking several times at once costs one call to the CLI: the lock is held across the fetch, so the goroutines behind it find the answer already there.