fix(googlechat): restore verification certificate retrieval after headers regression (#76742)#76791
fix(googlechat): restore verification certificate retrieval after headers regression (#76742)#76791SymbolStar wants to merge 2 commits into
Conversation
…ders regression (openclaw#76742) google-auth-library's AuthClient registers a request interceptor that calls config.headers.has() expecting a native Headers instance. After the stageRuntimeDependencies removal (ed8f50f), the bundled build's deep-clone utility (extend) can downgrade the Headers instance to a plain object, causing 'config.headers.has is not a function' when OAuth2Client.verifyIdToken() fetches federated sign-on certificates. Add a headers-normalizing request interceptor to the shared Gaxios transport that runs before the AuthClient interceptor, converting any plain-object headers back to a proper Headers instance.
openclaw-barnacle
Bot
added
channel: googlechat
|
Thanks for the context here. I did a careful shell check against current Current main already contains the Google Chat Google-auth header compatibility fix this PR was carrying, including request-header normalization, response-header normalization, focused tests, and changelog coverage; the later So I’m closing this as already implemented rather than keeping a duplicate issue open. Review detailsBest possible solution: Keep the plugin-owned header compatibility implementation on current main and track any remaining Do we have a high-confidence way to reproduce the issue? Yes, at source level: Google Chat Is this the best way to solve the issue? Yes: normalizing headers inside the Google Chat plugin's shared Google-auth transport is the narrow owner-local fix and preserves the SSRF-guarded fetch path. Current main also has the missing changelog coverage, so closing this now-obsolete PR is the best cleanup path. Security review: Security review cleared: The PR surface is limited to Google Chat auth runtime/tests, adds no dependencies or CI changes, and keeps Google auth requests on the existing SSRF-guarded transport. What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against da1e1435ad31; fix evidence: commit e5248789986c, main fix timestamp 2026-05-04T08:40:28+01:00. |
|
it changes, but doesn't resolve. now I get this error: """ |
|
That progresses, but now there's another error: """ |
2 participants
Fixes #76742
Root Cause
google-auth-library'sAuthClientregisters aDEFAULT_REQUEST_INTERCEPTORthat callsconfig.headers.has('x-goog-api-client'), expectingconfig.headersto be a nativeHeadersinstance.After the
stageRuntimeDependenciesremoval in ed8f50f, the bundled build's deep-clone utility (extend) used by gaxios's#prepareRequestcan downgrade aHeadersinstance to a plain object whose prototype methods (.has(),.set(), etc.) are lost. This causes:when
OAuth2Client.verifyIdToken()→getFederatedSignonCertsAsync()fetches federated sign-on certificates through the shared Gaxios transport.Fix
Add a headers-normalizing request interceptor to the shared Gaxios transport in
getGoogleAuthTransport(). This interceptor runs before the AuthClient interceptor and converts any plain-object headers back to a properHeadersinstance. If headers are already aHeadersinstance, they are left untouched.Tests
HeadersinstancesHeadersinstances are passed through unchanged