Skip to content

Add --access-token flag + HTTP_PROXY/HTTPS_PROXY support#419

Closed
mmkal wants to merge 4 commits intoopenclaw:mainfrom
mmkal:mmkal/26/01/28/--access-token
Closed

Add --access-token flag + HTTP_PROXY/HTTPS_PROXY support#419
mmkal wants to merge 4 commits intoopenclaw:mainfrom
mmkal:mmkal/26/01/28/--access-token

Conversation

@mmkal
Copy link
Copy Markdown

@mmkal mmkal commented Mar 5, 2026

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:

  1. Add an --access-token CLI option and GOG_ACCESS_TOKEN env var for supplying the access token directly. We need this because our "access token" always looks like the literal value getIterateSecret("google.access_token") which gets replaced with the actual, refreshed-and-up-to-date token in the proxy
  2. Add support for custom CA certs (we have a local cert for our MITM proxy) and HTTP_PROXY/HTTPS_PROXY env vars. We need this because it tells outgoing requests to use the proxy. If they don't use the proxy and hit Google directly, the access token will be rejected because it's just getIterateSecret("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)

mmkal added 4 commits March 5, 2026 09:38
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.
@tbvl
Copy link
Copy Markdown

tbvl commented Mar 5, 2026

+1 Came here for this, hope it gets merged.

@steipete
Copy link
Copy Markdown
Collaborator

steipete commented Mar 7, 2026

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.

@steipete steipete closed this Mar 7, 2026
@steipete
Copy link
Copy Markdown
Collaborator

steipete commented Mar 7, 2026

Salvaged the useful part directly onto main in 11efb05: direct --access-token / GOG_ACCESS_TOKEN auth, account fallback, docs, and regression coverage.

I 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.

@mmkal
Copy link
Copy Markdown
Author

mmkal commented Mar 7, 2026

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.

klodr pushed a commit to klodr/gogcli that referenced this pull request Apr 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants