dapr-api-token not pass to app when invoking dapr sidecar of an Azure Container App.
MingGitTest opened this issue · comments
I have deployed an Azure Container App and enabled the Dapr. I added authentication as well for the app like the following:
builder.Services.AddAuthentication(" ").AddDapr(options => options.Token = token);
builder.Services.AddAuthorization(options => options.AddDapr());
...
app.UseAuthentication();
app.UseAuthorization();
I have to set the Target Port to 3500 to allow invoking dapr directly from postman.
the thing is, when I tried to invoke dapr sidecar in postman like this:
https://myapp.azurecontainerapps.io/v1.0/invoke/my-app-id/method/my-method
I got 401 unauthorized error. I already added the dapr-api-token in headers.
The following is the log stream:
User-Agent: PostmanRuntime/7.36.0
Accept-Encoding: gzip, deflate, br
Referer: [Redacted]
traceparent: [Redacted]
Dapr-Api-Token: reqRk3F-sXgaxh-6a7BEow
Postman-Token: [Redacted]
Proto: [Redacted]
Protomajor: [Redacted]
Protominor: [Redacted]
X-Arr-Ssl: [Redacted]
X-Envoy-Expected-Rq-Timeout-Ms: [Redacted]
X-Envoy-External-Address: [Redacted]
X-Forwarded-For: [Redacted]
X-Forwarded-Proto: [Redacted]
X-K8se-App-Kind: [Redacted]
X-K8se-App-Name: [Redacted]
X-K8se-App-Namespace: [Redacted]
X-K8se-Protocol: [Redacted]
X-Ms-Containerapp-Name: [Redacted]
X-Ms-Containerapp-Revision-Name: [Redacted]
X-Request-Id: [Redacted]
info: Dapr.AspNetCore.DaprAuthenticationHandler[7]
Dapr was not authenticated. Failure message: Not authenticated.
info: Dapr.AspNetCore.DaprAuthenticationHandler[12]
AuthenticationScheme: Dapr was challenged.
The dapr-api-token received by the container app is not the one I set in header.
If I change the Target Port to 80 in Ingress of Azure Portal, I can use http (not hitting dapr) with same dapr-api-token header to invoke the app without issue though, like this:
https://myapp.azurecontainerapps.io/my-method
I am confused. Any idea what I missed?
@MingGitTest - Thanks for opening the issue. For my clarification, the main issue you're facing is that using a Dapr API Token does not function in container apps? Or, more specifically, that the token is not the one you sent in your original request?
How are you deploying Dapr to container apps? I believe the token needs to be set on the actual deployment.
I'll see if I can find some time to repro this though.
@halspang Thanks for the response. If I set the Target Port of Ingress to 80 in Azure portal and invoke the app using https://myapp.azurecontainerapps.io/my-method, it will work. The dapr-api-token is right and authentication works as expected. The problem is when I invoke dapr sidecar in postman like this:
https://myapp.azurecontainerapps.io/v1.0/invoke/my-app-id/method/my-method
I got 401 unauthorized error. The app is listening on 3500 now and the logged dapr-api-token is not the one I sent.
I published the app to azure using visual studio. Not sure what is the right way to set the Dapr token. I set both dapr and app api token in azure container app as Environment Variable and did not work either.
Any pointer would be appreciated.
I don't see any docs for using Container Apps with the DAPR_API_TOKEN but I do see a document for the APP_API_TOKEN. The difference here being that APP_API_TOKEN is used for communication from Dapr to your app, not the other way around.
My concern in their being only one document here is that they may not be exposing the ability to use DAPR_API_TOKEN. The also state that they randomly generate the APP_API_TOKEN. So maybe something similar is happening here which is why you may be seeing an issue with the token?
https://learn.microsoft.com/en-us/azure/container-apps/dapr-authentication-token?tabs=sdk
@halspang Thanks for the response. Yes I read the link as well and it fits my needs to authenticate all the requests to Dapr. However, I am kind of confused because in my project, if I connect to http 80, everything works. The dapr token is passed and authentication works. But if I tried to connect to dapr (port 3500) using invoke, the token passed is not the one I sent. It is more like an encoded value. Anyone has any idea? Any perspective would be appreciated.