fix(vertex): support API-key/context-header auth in cached content methods - #5462
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughSummary by CodeRabbit
WalkthroughVertex cached-content authentication now uses an API key query parameter when provided and preserves existing authorization headers. It retains OAuth bearer-token handling when no API key is provided. A test covers the API key behavior. ChangesVertex authentication
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.12.2)level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies" Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The merge-base changed after approval.
…thods The Vertex cached content methods (create/list/retrieve/update/delete) all authenticate via the shared vertexAuthHeaders helper, which unconditionally fetched an OAuth token from the key credentials and overwrote the Authorization header. This mirrors the pre-fix Embedding behaviour and prevents callers from supplying their own bearer token via context extra headers (e.g. a proxy that holds short-lived credentials out of band). Make vertexAuthHeaders take the API-key query-parameter path when the key carries a value — the same escape hatch the Gemini generation endpoints already use — leaving any Authorization header set from context extra headers intact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Charlie Gildawie <charlieg@monzo.com>
4254405 to
6609315
Compare
|
I updated this branch to resolve conflicts. Please review and merge if you are happy with this change. |
|
Heya -- Gentle prod to see if this could be merged if it's acceptable please. |
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
…thods (#5462) The Vertex cached content methods (create/list/retrieve/update/delete) all authenticate via the shared vertexAuthHeaders helper, which unconditionally fetched an OAuth token from the key credentials and overwrote the Authorization header. This mirrors the pre-fix Embedding behaviour and prevents callers from supplying their own bearer token via context extra headers (e.g. a proxy that holds short-lived credentials out of band). Make vertexAuthHeaders take the API-key query-parameter path when the key carries a value — the same escape hatch the Gemini generation endpoints already use — leaving any Authorization header set from context extra headers intact. Signed-off-by: Charlie Gildawie <charlieg@monzo.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Akshay Deo <akshay@akshaydeo.com>
…thods (maximhq#5462) The Vertex cached content methods (create/list/retrieve/update/delete) all authenticate via the shared vertexAuthHeaders helper, which unconditionally fetched an OAuth token from the key credentials and overwrote the Authorization header. This mirrors the pre-fix Embedding behaviour and prevents callers from supplying their own bearer token via context extra headers (e.g. a proxy that holds short-lived credentials out of band). Make vertexAuthHeaders take the API-key query-parameter path when the key carries a value — the same escape hatch the Gemini generation endpoints already use — leaving any Authorization header set from context extra headers intact. Signed-off-by: Charlie Gildawie <charlieg@monzo.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Akshay Deo <akshay@akshaydeo.com>

Summary
The Vertex cached content methods (create / list / retrieve / update / delete) all authenticate through the shared
vertexAuthHeadershelper, which unconditionally fetched an OAuth token from the key credentials and set it on theAuthorizationheader. BecauseSetExtraHeadersruns first andvertexAuthHeadersruns after, anyAuthorizationheader a caller injected via context extra headers was overwritten.This is the same limitation that affected
Embeddingbefore #4200. It prevents a caller that holds short-lived credentials out of band (e.g. a proxy/gateway) from supplying its own bearer token — the exact pattern the Gemini generation endpoints already support via the API-key query-parameter escape hatch.Changes
vertexAuthHeadersnow takes the API-key query-parameter path when the key carries a value (?key=<value>), mirroring the Gemini generation endpoints, and leaves an existingAuthorizationheader (set from context extra headers) intact. When the key has no value it falls back to the previous OAuth-token behaviour.Because every cached content method funnels through this one helper, the single change covers all five operations.
Type of change
Affected areas
How to Test
Added
TestVertexAuthHeaders_APIKeyPreservesInjectedAuthHeader(internalpackage vertex) asserting that, with an API-key-valued key, the injectedAuthorizationheader is preserved and thekeyquery parameter is set.Breaking changes
Related issues
Follow-up to #4200, which applied the same escape hatch to the
Embeddingmethod.Security considerations
No new auth mechanisms introduced. The change reuses the existing
authQuerypattern already present inChatCompletion(),Responses(), andResponsesStream(). The API key is URL-encoded viaurl.QueryEscapeconsistent with all other call sites.Checklist
docs/contributing/README.mdand followed the guidelines