dapr-api-token passed back to the application 'as-is' when proxying

[vermillionsword]

In what area(s)?

/area runtime

What version of Dapr?

1.11.2
1.12.2

Expected Behavior

I expect that when I proxy a service invocation through dapr using gRPC that the dapr-api-token header is updated to use the app-token-secret instead of the api-token-secret that I sent with my request.

Actual Behavior

I am instead receiving the same value I sent on the dapr-api-token header to the sidecar in the receiving service.

Steps to Reproduce the Problem

Setup:

• Run the latest dapr installation
• Run a plain gRPC service (C# preferably, though I assume this will happen with any proxied call)
• Turn on both dapr.io/app-token-secret: "app-api-token" and dapr.io/api-token-secret: "dapr-api-token"
• Create secrets as described in the documentation

Steps:

• Make a call to the service through dapr transparently (service proxying)
• Add dapr-api-token header to the request using the dapi-api-token secret
• Observe the dapr-api-token header, it will not be the app-api-token secret, instead it will still be the dapr-api-token secret

Release Note

RELEASE NOTE: FIX dapr-api-token header population for proxied calls

[vermillionsword]

The issue seems to be around line 138 of https://github.com/dapr/dapr/blob/master/pkg/messaging/grpc_proxy.go

Notice how the outgoing context does not get the dapr-api-token appended to it from security.GetAppToken() unlike

https://github.com/dapr/dapr/blob/master/pkg/channel/grpc/grpc_channel.go

[yaron2]

The issue seems to be around line 138 of https://github.com/dapr/dapr/blob/master/pkg/messaging/grpc_proxy.go

Notice how the outgoing context does not get the dapr-api-token appended to it from security.GetAppToken() unlike

https://github.com/dapr/dapr/blob/master/pkg/channel/grpc/grpc_channel.go

Yes, you've correctly identified where the token needs to be added. Would you be interested in opening a PR for this?

[vermillionsword]

@yaron2 sure. I think I can do that.

[yaron2]

Great. I've triaged it to 1.13 and we can accept this PR after our code freeze (already in effect) due to the security fix. cc @JoshVanL

[JoshVanL]

Fixed in #7404