Success response headers are not added to the response

[averevki]

Describe the bug
Since kuadrant-operator-catalog nightly builds from 28-29.01.25 our tests that should return custom success response headers started failing. They don't add these headers into the response anymore. Here is the most simple test for responses we got that is failing with AssertionError: Header from response (Header) is missing; assert None is not None

We were experiencing the same failures a few months ago, which ended up being a bug inside the wasm-shim, and was fixed by this PR.

Help us Reproduce it

AuthPolicy:

spec:
  rules:
    authentication:
      default:
        credentials:
          authorizationHeader:
            prefix: Bearer
        jwt:
          issuerUrl: 'http://1.2.3.4:8080/realms/realm-averevki--eyt7'
          ttl: 0
        metrics: false
        priority: 0
    response:
      success:
        headers:
          header:
            json:
              properties:
                anything:
                  value: one
            metrics: false
            priority: 0
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: route-averevki--obnu

Gateway

spec:
  gatewayClassName: istio
  listeners:
    - allowedRoutes:
        namespaces:
          from: Same
      hostname: '*.apps.kua.redhat.com'
      name: api
      port: 80
      protocol: HTTP

HTTPRoute

spec:
  hostnames:
    - hostname-averevki--nbep-kuadrant.apps.kua.redhat.com
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: gw-averevki--ljiu
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: httpbin-averevki--ihex
          namespace: kuadrant
          port: 8080
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /

Expected behavior

Return headers I specify inside AuthPolicy with a successful response

Environment (please complete the following information):

kuadrant-operator image: nightly-04-02-2025
authorino-operator image: e1dc399c6bcb2fb6d28b2f3e94ce49bb5b63e06c
authorino image: b2bde91bfc64b1d140f740069ba36ce81a3f3349
wasm-shim image: 751af05ea5e6c440d6254480d669bc5861f457eb

[adam-cattermole]

This may be related to the recent wasm-shim refactor (dates look to match) - I'll take a look

[adam-cattermole]

I'm not sure I can reproduce this in the wasm-shim actually, even though the dates match up it seems to be working perfectly:

apiVersion: authorino.kuadrant.io/v1beta3
kind: AuthConfig
metadata:
  name: talker-api-protection
spec:
  hosts:
    - effective-route-1
  authentication:
    "api-key-users":
      apiKey:
        selector:
          matchLabels:
            app: toystore
      credentials:
        authorizationHeader:
          prefix: APIKEY
  response:
    success:
      headers:
        header:
          json:
            properties:
              "anything":
                value: false

This authconfig returns:

$ curl -H "Host: test.a.auth.com" -H "Authorization: APIKEY IAMALICE" http://127.0.0.1:8000/get -i
HTTP/1.1 200 OK
content-type: application/json
server: envoy
date: Wed, 05 Feb 2025 11:27:54 GMT
content-length: 507
x-envoy-upstream-service-time: 21
header: {"anything":false}

{
  "method": "GET",
  "path": "/get",
  "query_string": null,
  "body": "",
  "headers": {
    "Host": "test.a.auth.com",
    "User-Agent": "curl/8.7.1",
    "Accept": "*/*",
    "Authorization": "APIKEY IAMALICE",
    "X-Forwarded-For": "10.244.0.10",
    "X-Forwarded-Proto": "http",
    "X-Envoy-Internal": "true",
    "X-Request-Id": "cb37d20d-bbae-417a-9f64-312e49ec4dfe",
    "X-Envoy-Expected-Rq-Timeout-Ms": "15000",
    "Version": "HTTP/1.1"
  },
  "uuid": "0eaaa277-197d-4d1f-a936-552d52adf9a8"
}

edit: perhaps it response vs request headers, I'll continue to investigate

[adam-cattermole]

I'm not sure I can reproduce this in the wasm-shim actually, even though the dates match up it seems to be working perfectly
edit: perhaps it response vs request headers, I'll continue to investigate

Yep the headers are incorrectly added to the response instead of the request. I'll have a look what it takes to fix this