[Fix-2] RHCLOUD-47253: Extract credential type from request path/headers#125
Open
Adam0Brien wants to merge 22 commits into
Open
[Fix-2] RHCLOUD-47253: Extract credential type from request path/headers#125Adam0Brien wants to merge 22 commits into
Adam0Brien wants to merge 22 commits into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds configurable ordered credential sources for ext_authz (bearer, cookie, cert, query), implements extractors and tests, validates and maps config to runtime sources, refactors AuthzServer to use them and propagate extraction metadata, and surfaces the source as ChangesMulti-Source Credential Extraction
Sequence Diagram(s)sequenceDiagram
participant Client
participant AuthzServer
participant Extractor
participant TokenService
participant CELMapper
Client->>AuthzServer: ext_authz Check (request with bearer/cookie/query/cert)
AuthzServer->>Extractor: extractCredentialFromSources(request, configuredSources)
Extractor->>Extractor: try configured sources in order
Extractor-->>AuthzServer: credential + sourceType + headers/query removals + headerSets
AuthzServer->>TokenService: IssueRequest (with CredentialSourceType)
TokenService->>CELMapper: Map claims (MapperInput.CredentialSourceType)
CELMapper->>CELMapper: evaluate CEL using cred_type
CELMapper-->>TokenService: transformed claims
TokenService-->>AuthzServer: issued token
AuthzServer->>Client: ext_authz response (with dynamic headers/query removals)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
The latest Buf updates on your PR. Results from workflow buf-pull-request / build (pull_request).
|
Adam0Brien
changed the title
Member
Author
|
@coderabbitai full-review |
🧩 Analysis chainI'll start a full review of the PR. Let me gather all the necessary information first. 🏁 Script executed: Length of output: 11861 🏁 Script executed: Length of output: 26402 Let me check the Go version requirement and a few more things before writing the full review. 🏁 Script executed: Length of output: 842
SummaryThis PR introduces a clean, extensible credential extraction layer for ext_authz with support for Bearer, cookie, query-parameter, and certificate-based credentials. The functional-options pattern for
|
| Missing test | File |
|---|---|
extractCertCredential fallback to x-rh-certauth-cn |
credential_sources_test.go |
Unsupported source type (default branch in tryCredentialSource) |
credential_sources_test.go |
cookieValue with URL-encoded values or empty cookie value (cs_jwt=) |
credential_sources_test.go |
Cert extraction with a custom header: value (e.g. header: x-ssl-client-cert) |
credential_sources_test.go |
internal/config/provider.go
🟡 Missing early config validation
AuthzServerCredentialSources() only validates that type is non-empty. Source-type-specific requirements (e.g. that name is meaningful for cookie/query, or that header is a valid HTTP header name for cert) are only checked at extraction time. Consider failing fast at startup:
switch srcCfg.Type {
case "cookie", "query":
// Name defaults are applied at extraction time, OK
case "cert":
// Optionally validate header is a valid header name
case "bearer":
// No extra fields needed
default:
return nil, fmt.Errorf("credential_sources[%d]: unknown type %q", i, srcCfg.Type)
}internal/config/validators.go
🟢 Minor — Stub validator result fields are hardcoded
result := &trust.Result{
Subject: "test-subject",
Issuer: "https://test-issuer.example.com",
...
}For a stub/dev validator this is reasonable, but subject / issuer should ideally be overridable from config (e.g. cfg.Claims["sub"]) to produce more realistic test tokens. Not blocking.
internal/server/credential_sources.go — Minor
Bearer scheme is case-sensitive
token, ok := strings.CutPrefix(authHeader, "Bearer ")RFC 7235 specifies auth-scheme names are case-insensitive (bearer, BEARER, Bearer are all valid). This is pre-existing behaviour but now more visible. Consider strings.EqualFold on the prefix or strings.ToLower on the header before splitting.
Checklist of Positives ✅
- Clean functional options pattern for
AuthzServerwith backward-compatible default (bearerfallback when no sources configured) cred_typeCEL variable is well-plumbed through the entire pipeline (IssueRequest→IssueContext→MapperInput→ CEL activation)- Good test coverage for the happy path and fallthrough scenarios (
first matching source wins,falls through to second source) - Config YAML example is clear and well-commented
extractCredentialFromSourcesproperly guards againstnilHTTP attributes
✅ Actions performed
Full review triggered.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/config/provider.go`:
- Around line 394-402: The loop over p.config.AuthzServer.CredentialSources
currently only checks that Type is non-empty and defers other schema errors to
runtime; update the validation in the loop that builds sources (iterating
p.config.AuthzServer.CredentialSources) to fail-fast by: validating that Type is
one of the allowed values (e.g., "header","cookie","query", etc.), and for each
type enforce required fields (e.g., if Type == "header" require Header
non-empty; if Type == "cookie" or "query" require Name non-empty); return a
descriptive fmt.Errorf for any invalid or unknown type instead of appending an
invalid server.CredentialSource so startup rejects malformed configs.
In `@internal/server/authz.go`:
- Around line 42-49: Refactor the options to target a package-private config
struct (e.g., authzServerConfig) instead of mutating AuthzServer directly:
change the type AuthzServerOption to func(*authzServerConfig), update
WithCredentialSources to set config.CredentialSources on that config type, and
modify NewAuthzServer to create a default authzServerConfig, apply all
AuthzServerOption functions to it, then construct and return the public
AuthzServer instance using fields from the populated config; ensure any other
option functions in the same block follow the same pattern and that AuthzServer
remains immutable from options.
In `@internal/server/credential_sources.go`:
- Around line 148-152: The code silently falls back to
headers["x-rh-certauth-cn"] when certHeader is empty (the certHeader/header
assignment block); remove that implicit fallback and require explicit
configuration instead: either delete the fallback branch so certHeader/header
remain unchanged when not configured, or gate the assignment behind a clearly
named config flag (e.g., AllowCertHeaderFallback) and log a warning when using
the fallback; update any tests that assumed the implicit behavior and reference
the variables certHeader, header and the headers map when making the change.
- Around line 81-84: The Bearer scheme check using strings.CutPrefix(authHeader,
"Bearer ") is case-sensitive and will reject "bearer ..."; instead normalize the
scheme portion to lowercase before checking: compute a lowercased prefix (e.g.,
strings.ToLower(authHeader)) or split on whitespace to inspect the scheme, then
extract the token into the existing token variable and preserve the original
token casing; update the logic around authHeader, token, and the CutPrefix usage
so it accepts any case variation of "bearer" while still returning the token or
the same error when the scheme is not Bearer.
- Around line 108-112: The code currently returns credentialExtraction with
headers set to []string{"cookie"}, which removes the entire Cookie header;
instead parse the original Cookie header, filter out only the credential cookie
(e.g. "cs_jwt" or the token cookie used to build trust.BearerCredential),
rebuild a sanitized Cookie string containing the remaining cookies, and set the
credentialExtraction to include that sanitized cookie header (not a blanket
"cookie" removal). Update the return in the function that constructs
credentialExtraction so it computes sanitizedCookie by splitting/parsing the
original cookie string, omitting the credential name, and using that sanitized
value in headers (or the appropriate header-to-value form your codebase uses)
while leaving other cookies intact.
- Around line 115-138: extractBearerFromQuery currently returns a
credentialExtraction with sourceType "query" while leaving the token in the URL,
which Check() won't remove (it only strips headers) and thus leaks secrets; fix
by refusing query-based extraction: update extractBearerFromQuery to return an
error (e.g., "query token extraction not allowed") instead of a
credentialExtraction, or alternatively ensure the extraction sanitizes the path
by removing/overwriting the token before returning (so upstream never sees it);
reference extractBearerFromQuery, credentialExtraction and Check() when making
the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: a5271951-ad7e-4de6-8ee0-ccc932f1805b
📒 Files selected for processing (14)
configs/parsec.yamlinternal/cel/mapper_input.gointernal/cli/serve.gointernal/config/config.gointernal/config/provider.gointernal/config/validators.gointernal/mapper/cel_mapper.gointernal/mapper/cel_mapper_test.gointernal/server/authz.gointernal/server/credential_sources.gointernal/server/credential_sources_test.gointernal/service/issuer.gointernal/service/mapper.gointernal/service/service.go
…stead of at request time: enforce allowed types and required fields per type.
Apply AuthzServerOption against authzServerConfig and embed it in AuthzServer so credential sources are configured once at construction instead of mutating the server via options.
…wercase bearer tokens are accepted; token value casing is unchanged.
…eader on ext_authz Sanitize the Cookie header by removing the JWT cookie while keeping other cookies, using header override when cookies remain and full removal only when it was the sole cookie.
Set QueryParametersToRemove on ext_authz OK responses so tokens extracted from the URL are stripped and do not leak to backends.
Require the configured cert header only so cert credentials are not read from an undocumented alternate header.
Adam0Brien
requested review from
Rajagopalan-Ranganathan,
akoserwal,
alechenninger,
coderbydesign and
jharting
as code owners
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/server/authz.go`:
- Around line 179-186: The current loop that builds responseHeaders from
ext.headerSets creates corev3.HeaderValueOption entries without setting
AppendAction, causing Envoy to append sanitized headers instead of replacing
originals; update the construction of each corev3.HeaderValueOption (in the loop
over ext.headerSets where responseHeaders is appended) to set AppendAction to
corev3.HeaderValueOption_OVERWRITE_IF_EXISTS_OR_ADD so the sanitized header
overwrites any existing header rather than appending.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 900ff651-c99d-47b3-845b-169d6e3777ea
📒 Files selected for processing (5)
internal/config/provider.gointernal/config/provider_test.gointernal/server/authz.gointernal/server/credential_sources.gointernal/server/credential_sources_test.go
…ders Cookie credential sanitization returns a rewritten Cookie via HeaderSets; without AppendAction Envoy appends the value and the original credential header can still reach upstream.
There was a problem hiding this comment.
♻️ Duplicate comments (1)
internal/server/authz.go (1)
179-186:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSanitized headers must explicitly overwrite existing request headers.
Line 180 creates
corev3.HeaderValueOptionwithoutAppendAction. In Envoy, default behavior may append, which can keep original credential-bearing headers alongside sanitized values (notablycookie), breaking the intended security boundary.Proposed fix
for name, value := range ext.HeaderSets { responseHeaders = append(responseHeaders, &corev3.HeaderValueOption{ Header: &corev3.HeaderValue{ Key: name, Value: value, }, + AppendAction: corev3.HeaderValueOption_OVERWRITE_IF_EXISTS_OR_ADD, }) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/server/authz.go` around lines 179 - 186, The loop that builds responseHeaders from ext.HeaderSets uses corev3.HeaderValueOption without setting AppendAction, so Envoy may append instead of replacing headers; update the construction in the ext.HeaderSets loop (where responseHeaders is appended) to set AppendAction to corev3.HeaderValueOption_OVERWRITE on each corev3.HeaderValueOption so sanitized headers (e.g., cookie, authorization) explicitly overwrite any existing request headers.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@internal/server/authz.go`:
- Around line 179-186: The loop that builds responseHeaders from ext.HeaderSets
uses corev3.HeaderValueOption without setting AppendAction, so Envoy may append
instead of replacing headers; update the construction in the ext.HeaderSets loop
(where responseHeaders is appended) to set AppendAction to
corev3.HeaderValueOption_OVERWRITE on each corev3.HeaderValueOption so sanitized
headers (e.g., cookie, authorization) explicitly overwrite any existing request
headers.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: c3eba967-0d30-44f8-b7bf-e488f3b78542
📒 Files selected for processing (8)
internal/config/provider.gointernal/server/authz.gointernal/server/bearer_credential_source.gointernal/server/cert_credential_source.gointernal/server/cookie_credential_source.gointernal/server/credential_sources.gointernal/server/credential_sources_test.gointernal/server/query_credential_source.go
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/server/authz.go (1)
171-177:⚠️ Potential issue | 🟠 Major | ⚡ Quick winIssued token headers should overwrite to prevent header spoofing.
These headers lack
AppendAction, defaulting toAPPEND_IF_EXISTS_OR_ADD. If an attacker sends a pre-existingTransaction-Tokenheader, the real token is appended rather than replacing it. The backend then receives both headers, potentially processing the attacker-controlled value first. This undermines the security boundary the ext_authz is meant to create.Proposed fix
for _, spec := range s.TokenTypesToIssue { if token, ok := issuedTokens[spec.Type]; ok { responseHeaders = append(responseHeaders, &corev3.HeaderValueOption{ Header: &corev3.HeaderValue{ Key: spec.HeaderName, Value: token.Value, }, + AppendAction: corev3.HeaderValueOption_OVERWRITE_IF_EXISTS_OR_ADD, }) } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/server/authz.go` around lines 171 - 177, The header being added via corev3.HeaderValueOption should explicitly set the AppendAction to overwrite existing headers to prevent header spoofing; update the code that constructs the HeaderValueOption (where responseHeaders is appended and spec.HeaderName / token.Value are used) to set AppendAction to the enum value that overwrites existing headers (HeaderValueOption_OVERWRITE_IF_EXISTS_OR_ADD) so the ext_authz header replaces any attacker-supplied header instead of appending.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@internal/server/authz.go`:
- Around line 171-177: The header being added via corev3.HeaderValueOption
should explicitly set the AppendAction to overwrite existing headers to prevent
header spoofing; update the code that constructs the HeaderValueOption (where
responseHeaders is appended and spec.HeaderName / token.Value are used) to set
AppendAction to the enum value that overwrites existing headers
(HeaderValueOption_OVERWRITE_IF_EXISTS_OR_ADD) so the ext_authz header replaces
any attacker-supplied header instead of appending.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 93b17335-7b3e-461c-a058-680c88c24300
📒 Files selected for processing (1)
internal/server/authz.go
…oofing Set AppendAction to OVERWRITE_IF_EXISTS_OR_ADD on token HeaderValueOption entries so parsec-issued headers (e.g. Transaction-Token) replace any client-supplied value instead of appending alongside it.
Use name to identify each credential source (like validators and data sources), cookie_name and parameter_name for type-specific settings, and validate names are unique at load time. cred_type in CEL now reports the configured source name so multiple sources of the same type can be distinguished.
Rename cred_type to cred_source_name and CredentialSourceType to CredentialSourceName so mappers can identify which configured source matched, avoiding confusion when multiple sources share the same type.
Build server credential sources from CredentialSourceConfig in config, matching data source and observer patterns. Remove the duplicate CredentialSourceSpec and keep server types focused on extraction only.
Remove the placeholder cert credential source from this PR. It incorrectly wrapped XFCC header material in BearerCredential; proper MTLSCredential parsing and validation will land in a dedicated [Fix-3] sub-task under RHCLOUD-46385. This change keeps bearer, cookie, and query extraction only.
Rename TransportContext to CredentialContext, encapsulate credential source stamping in validateCredential, and move credential_sources to top-level config so authz and exchange share the same sources.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Template:
Describe your changes
Config
Testing
Bearer
Result
{ "status": {}, "okResponse": { "headers": [ { "header": { "key": "Transaction-Token", "value": "stub-txn-token.test-subject.txn-1779107786145237.{\"host\":\"\",\"ip_address\":\"127.0.0.1\",\"method\":\"GET\",\"path\":\"/api/test\"}" } }, { "header": { "key": "x-rh-identity", "value": "eyJlbnRpdGxlbWVudHMiOnt9LCJpZGVudGl0eSI6eyJhY2NvdW50X251bWJlciI6IjU0MzIxIiwiYXV0aF90eXBlIjoiand0LWF1dGgiLCJpbnRlcm5hbCI6eyJhdXRoX3RpbWUiOjE3NzkxMDc3ODYxNDUsImNyb3NzX2FjY2VzcyI6ZmFsc2UsIm9yZ19pZCI6IjEyMzQ1In0sIm9yZ19pZCI6IjEyMzQ1IiwidHlwZSI6IlVzZXIiLCJ1c2VyIjp7ImVtYWlsIjoiZGV2QGV4YW1wbGUuY29tIiwiZmlyc3RfbmFtZSI6IkRldiIsImlzX2FjdGl2ZSI6dHJ1ZSwiaXNfaW50ZXJuYWwiOmZhbHNlLCJpc19vcmdfYWRtaW4iOmZhbHNlLCJsYXN0X25hbWUiOiJVc2VyIiwibG9jYWxlIjoiIiwidXNlcl9pZCI6IiIsInVzZXJuYW1lIjoiZGV2LXVzZXIifX19" } } ], "headersToRemove": [ "authorization" ] } }Cookie
Result
{ "status": {}, "okResponse": { "headers": [ { "header": { "key": "Transaction-Token", "value": "stub-txn-token.test-subject.txn-1779114197327907.{\"host\":\"\",\"ip_address\":\"127.0.0.1\",\"method\":\"GET\",\"path\":\"/api/test\"}" } }, { "header": { "key": "x-rh-identity", "value": "eyJlbnRpdGxlbWVudHMiOnt9LCJpZGVudGl0eSI6eyJhY2NvdW50X251bWJlciI6IjU0MzIxIiwiYXV0aF90eXBlIjoiand0LWF1dGgiLCJpbnRlcm5hbCI6eyJhdXRoX3RpbWUiOjE3NzkxMTQxOTczMjgsImNyb3NzX2FjY2VzcyI6ZmFsc2UsIm9yZ19pZCI6IjEyMzQ1In0sIm9yZ19pZCI6IjEyMzQ1IiwidHlwZSI6IlVzZXIiLCJ1c2VyIjp7ImVtYWlsIjoiZGV2QGV4YW1wbGUuY29tIiwiZmlyc3RfbmFtZSI6IkRldiIsImlzX2FjdGl2ZSI6dHJ1ZSwiaXNfaW50ZXJuYWwiOmZhbHNlLCJpc19vcmdfYWRtaW4iOmZhbHNlLCJsYXN0X25hbWUiOiJVc2VyIiwibG9jYWxlIjoiIiwidXNlcl9pZCI6IiIsInVzZXJuYW1lIjoiZGV2LXVzZXIifX19" } }, { "header": { "key": "cookie", "value": "session=abc" } } ] } }Query
Result
{ "status": {}, "okResponse": { "headers": [ { "header": { "key": "Transaction-Token", "value": "stub-txn-token.test-subject.txn-1779114832725989.{\"host\":\"\",\"ip_address\":\"127.0.0.1\",\"method\":\"GET\",\"path\":\"/api/test?token=eyJlbnRpdGxlbWVudHMiOnt9LCJpZGVudGl0eSI6eyJhY2NvdW50X251bWJlciI6IjU0MzIxIiwiYXV0aF90eXBlIjoiand0LWF1dGgiLCJpbnRlcm5hbCI6eyJhdXRoX3RpbWUiOjE3NzkxMDMzMDcyODgsImNyb3NzX2FjY2VzcyI6ZmFsc2UsIm9yZ19pZCI6IjEyMzQ1In0sIm9yZ19pZCI6IjEyMzQ1IiwidHlwZSI6IlVzZXIiLCJ1c2VyIjp7ImVtYWlsIjoiZGV2QGV4YW1wbGUuY29tIiwiZmlyc3RfbmFtZSI6IkRldiIsImlzX2FjdGl2ZSI6dHJ1ZSwiaXNfaW50ZXJuYWwiOmZhbHNlLCJpc19vcmdfYWRtaW4iOmZhbHNlLCJsYXN0X25hbWUiOiJVc2VyIiwibG9jYWxlIjoiIiwidXNlcl9pZCI6IiIsInVzZXJuYW1lIjoiZGV2LXVzZXIifX19\"}" } }, { "header": { "key": "x-rh-identity", "value": "eyJlbnRpdGxlbWVudHMiOnt9LCJpZGVudGl0eSI6eyJhY2NvdW50X251bWJlciI6IjU0MzIxIiwiYXV0aF90eXBlIjoiand0LWF1dGgiLCJpbnRlcm5hbCI6eyJhdXRoX3RpbWUiOjE3NzkxMTQ4MzI3MjYsImNyb3NzX2FjY2VzcyI6ZmFsc2UsIm9yZ19pZCI6IjEyMzQ1In0sIm9yZ19pZCI6IjEyMzQ1IiwidHlwZSI6IlVzZXIiLCJ1c2VyIjp7ImVtYWlsIjoiZGV2QGV4YW1wbGUuY29tIiwiZmlyc3RfbmFtZSI6IkRldiIsImlzX2FjdGl2ZSI6dHJ1ZSwiaXNfaW50ZXJuYWwiOmZhbHNlLCJpc19vcmdfYWRtaW4iOmZhbHNlLCJsYXN0X25hbWUiOiJVc2VyIiwibG9jYWxlIjoiIiwidXNlcl9pZCI6IiIsInVzZXJuYW1lIjoiZGV2LXVzZXIifX19" } } ], "queryParametersToRemove": [ "token" ] } }Cert
Result
{ "status": {}, "okResponse": { "headers": [ { "header": { "key": "Transaction-Token", "value": "stub-txn-token.test-subject.txn-1779114864917438.{\"host\":\"\",\"ip_address\":\"127.0.0.1\",\"method\":\"GET\",\"path\":\"/api/test\"}" } }, { "header": { "key": "x-rh-identity", "value": "eyJlbnRpdGxlbWVudHMiOnt9LCJpZGVudGl0eSI6eyJhY2NvdW50X251bWJlciI6IjU0MzIxIiwiYXV0aF90eXBlIjoiand0LWF1dGgiLCJpbnRlcm5hbCI6eyJhdXRoX3RpbWUiOjE3NzkxMTQ4NjQ5MTcsImNyb3NzX2FjY2VzcyI6ZmFsc2UsIm9yZ19pZCI6IjEyMzQ1In0sIm9yZ19pZCI6IjEyMzQ1IiwidHlwZSI6IlVzZXIiLCJ1c2VyIjp7ImVtYWlsIjoiZGV2QGV4YW1wbGUuY29tIiwiZmlyc3RfbmFtZSI6IkRldiIsImlzX2FjdGl2ZSI6dHJ1ZSwiaXNfaW50ZXJuYWwiOmZhbHNlLCJpc19vcmdfYWRtaW4iOmZhbHNlLCJsYXN0X25hbWUiOiJVc2VyIiwibG9jYWxlIjoiIiwidXNlcl9pZCI6IiIsInVzZXJuYW1lIjoiZGV2LXVzZXIifX19" } } ], "headersToRemove": [ "x-forwarded-client-cert" ] } }Deny
Result
{ "status": { "code": 16, "message": "failed to extract credentials: query parameter \"token\" not found" }, "deniedResponse": { "body": "failed to extract credentials: query parameter \"token\" not found" } }Ticket reference (if applicable)
Fixes #
Checklist
Are the agreed upon acceptance criteria fulfilled?
Was the 4-eye-principle applied? (async PR review, pairing, ensembling)
Do your changes have passing automated tests and sufficient observability?
Are the work steps you introduced repeatable by others, either through automation or documentation?
The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)
Are the agreed upon coding/architectural practices applied?
Are security needs fullfilled? (e.g. no internal URL)
Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)
For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?
Summary by CodeRabbit
New Features
Tests