Add --access-token flag + HTTP_PROXY/HTTPS_PROXY support#419
Add --access-token flag + HTTP_PROXY/HTTPS_PROXY support#419mmkal wants to merge 4 commits intoopenclaw:mainfrom
Conversation
Add support for passing an access token directly via --access-token flag or GOG_ACCESS_TOKEN environment variable. This enables headless/CI usage without browser-based OAuth or keyring access. To test this feature: ```bash git clone https://github.com/mmkal/gogcli cd gogcli git checkout mmkal/26/01/28/--access-token make build ./bin/gog gmail labels list --access-token "$(gcloud auth print-access-token)" export GOG_ACCESS_TOKEN="ya29.a0AfH6SM..." ./bin/gog gmail labels list ``` If you have a refresh token managed externally, exchange it: ```bash curl -X POST https://oauth2.googleapis.com/token \ -d "client_id=YOUR_CLIENT_ID" \ -d "client_secret=YOUR_CLIENT_SECRET" \ -d "refresh_token=YOUR_REFRESH_TOKEN" \ -d "grant_type=refresh_token" ``` - internal/authclient/authclient.go: Added WithAccessToken() and AccessTokenFromContext() context helpers (similar to existing WithClient/ClientOverrideFromContext pattern) - internal/cmd/root.go: Added AccessToken field to RootFlags with env:"GOG_ACCESS_TOKEN" tag, wired context injection in Execute(), and added stderr warning about token expiry - internal/googleapi/client.go: Modified optionsForAccountScopes() to check for access token in context first and use oauth2.StaticTokenSource when present (bypassing refresh token flow entirely) - internal/cmd/account.go: Modified requireAccount() to make --account optional when --access-token is provided (returns placeholder account) - Access tokens expire in ~1 hour; long-running operations may fail - No automatic refresh—users must provide fresh tokens - No scope validation—API errors if token lacks required scopes - A warning is printed to stderr when using this mode Added unit tests for: - authclient context helpers (authclient_test.go) - optionsForAccountScopes with access token bypass (client_more_test.go)
When running gogcli through a MITM proxy (e.g., mitmproxy, corporate proxies), TLS certificate verification would fail with: tls: failed to verify certificate: x509: certificate signed by unknown authority This happened because the HTTP transport didn't load custom CA certificates from the standard SSL_CERT_FILE environment variable. Added buildTLSConfig() helper that: 1. Loads the system cert pool 2. On Linux, explicitly loads system CA bundles from well-known paths (Debian/Ubuntu, RHEL/CentOS, OpenSUSE) as a fallback for CGO_ENABLED=0 builds where x509.SystemCertPool() may not include all system certs 3. Appends certs from SSL_CERT_FILE if set (standard env var for custom CAs) 4. Enforces TLS 1.2 minimum Applied this config to both: - The main API client transport in optionsForAccountScopes() - The OAuth2 token refresh HTTP client in tokenSourceForAccountScopes() To use with a MITM proxy: ```bash SSL_CERT_FILE=/path/to/mitmproxy-ca-cert.pem gog gmail labels list --access-token "..." ``` Debug logging (with --verbose) shows when custom certs are loaded.
The custom http.Transport instances were missing the Proxy field, so requests wouldn't go through proxies configured via HTTP_PROXY or HTTPS_PROXY environment variables. Added Proxy: http.ProxyFromEnvironment to both: - The main API client transport in optionsForAccountScopes() - The OAuth2 token refresh HTTP client in tokenSourceForAccountScopes() This is needed in sandboxed environments where an egress proxy handles secret substitution or network routing.
|
+1 Came here for this, hope it gets merged. |
|
Salvaged the useful part directly onto main in 11efb05: direct \ / \ auth, account fallback, docs, and regression coverage.\n\nI did not carry the proxy/TLS parts over because that intent was already on main earlier (proxy support landed in #228, and the current transport stack already honors environment proxies). Closing this PR as superseded by the direct main landing. |
|
Salvaged the useful part directly onto I did not carry the proxy/TLS parts over because that intent was already on |
|
Nice, thanks! Will try out the main branch, haven't looked at #228 but hopefully it covers our use case. If not (we had some trouble with our CA) I can open a new PR. |
Hello!
We are using gogcli over at https://github.com/iterate/iterate (open-source but WIP as a product, we use internally)
But we use an http proxy system to prevent agents from being able to see user secrets. We have a separate layer which manages refresh + access tokens and swaps out placeholders (which the agent can see) for real secrets in the proxy. This meant we had to make two changes to the CLI:
--access-tokenCLI option andGOG_ACCESS_TOKENenv var for supplying the access token directly. We need this because our "access token" always looks like the literal valuegetIterateSecret("google.access_token")which gets replaced with the actual, refreshed-and-up-to-date token in the proxygetIterateSecret("google.access_token").The TLS/proxy changes piggyback on the newBaseTransport() thing that already exists on main.
We're using this fork already, which is nice, but figured it'd make sense to merge to upstream. (Assuming gogcli will continue to be a thing now google published something similar officially)