Azure functions can not support send a http request with Authorization header

[v-limliu]

HttpClient client = new HttpClient(); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "**********"); var response = client.GetAsync("***************").Result.Content.ReadAsStringAsync().Result;

these code run very well in local with azure-functions-core-tools, but not well in the production environment that in azure . Can you help me to solve this case. thanks very much.

this is my execution id :Function completed (Failure, Id=b0ddfab2-e451-4eb1-a7c4-9462a7cf879b, Duration=12392ms)

[christopheranderson]

@davidebbo - Can you please attempt to repro this? (Fixing to current on call)

[ahmelsayed]

@v-limliu what do you mean exactly by it doesn't work on azure? are you getting some kind of error? or does it never finish?

just looking at the code

var response = client.GetAsync("***************").Result.Content.ReadAsStringAsync().Result;

is a wrong pattern that will almost certainly cause deadlocks for you.

change it to

var response = await client.GetAsync("***************");
var content = await response.Content.ReadAsStringAsync();

[us-dev]

Is this still an active issue? I am also having similar problem,

I have an HTTP Client where I am setting the Autorization.

When I run it locally, I can see the Authorization Header and the other API that accepts the HTTP call from Function works well.

When I run everything in Azure, I can see that the Azure Function has the Header in the httprequest object but the Azure WebApp throws 401 since it is unable to find that "Authorization" header at all. I am logging the RequestHeaders in the WebApp by adding middleware and it logs all the header and Auth is missing.

However, when I target my local Function code to target Azure WebApp, then it works fine as well.

// Function Code: _httpClientHelper.AddAuthorizationHeader(new AuthenticationHeaderValue("Bearer", token)); _httpClientHelper.AddHeader("Access-Control-Allow-Credentials", "true");

[mattchenderson]

@us-dev can you please share a reliable repro? We don't have one on our end.

[us-dev]

I never got around to solving the actual issue. For the time being, I added a custom header in the Fn code (something like "CustomAuthorization") and then on the webapp side I added a middleware where it will intercept every calls and then will replace the custom header with the "Authorization" header. After that, the controller will get the request and the normal AuthZ can happen.

This works if you have control over the receiving webapp.

I haven't tried this with the new v3 yet :(

[atamu]

@us-dev Did you have App Service Authentication enabled in both functions- using bearer token authentication within the first function to access the second?

I've hit a similar issue, and can replicate it when enabling App Service Authentication (Log in with Azure Active Directory) set in the second function. Running locally the request is successful against the second function in Azure, but when deployed into Azure the HTTP request to the second function results in a 401.

client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json")); client.DefaultRequestHeaders.Add("Access-Control-Allow-Credentials", "true"); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken); var response = client.GetAsync(requestUri).Result;

The token retrieved by the first function in Azure can be used to access the intended resource (tested via postman also).

It appears Microsoft.Azure.AppService.Middleware.EasyAuthModule does support token authentication but something unexpected is happening when calling from another function. (Function ~2 platform)

This is the only issue report I can see which is remotely close to this, so it must be something quite obscure.

[tplive]

I have a similar issue where the client succeeds on the first request, but fails on subsequent requests. The cause is, as far as I've been able to tell, that using DefaultRequestHeaders.Add directly causes the headers to be added again on subsequent requests, since the HttpClient is being reused (as it should). DefaultRequestHeaders should only be added once for the lifetime of the HttpClient. I have yet to find something that solves my problem, but I find suggestions using extension methods to configure each request.