We have 2 Linux Web apps running in Azure ( blessed images, not custom ones) running on .NET 6 with custom domains - one API and an MVC app. It's a multitenant organization and the API is using the host header from the incoming HTTP request to resolve a tenants database. So far so good - on IIS everything is working great - we are setting the host header in the HttpClientFactory with the correct domain name, sending the request and the API does its job.
Now the problem - when deployed to Azure, when we set the header to the domain from which the request should be sent(which is the domain we are currently on), the container goes in to a loop when the first HTTP request occurs, executing this request over and over again and after some time our timeout DelegateHandler on the HttpClient is being hit. If we do not set the header the loop stops but we do not have the correct Host header in the request and our API is unable to process the request.
I know there is a reverse proxy which is resolving which web app should process the request based on the custom domain in Azure and I am pretty sure that's our problem but I am not very familiar with Azure architecture and don't know what to do.
P.S. If we use a custom header and set there the host name and reconfigure the API to use this custom request header everything works fine, but that's not what we want.
So any help would be of great help.
Related
Our Web API setup is done in an Azure kubernetes cluster with nginx as ingress controller and Lets encrypt for https.
In the staging namespace all is fine, the swagger UI is accesible using https and the server shows the server as https as well.
The same setup on prod namespace shows the swagger ui as https but the server as http only. Also try to execute any API functions fails.
Any idea what can go wrong with passinge the scheme information from nginx to the service running the API? As far as I know the communication between nginx and the service is http only.
The docker image for the server is the same and the ingresses for staging and prod only differ service names and host names.
Best regards
I have an application that is broken up into 3 tiers. I have Identity Server 4, a Web API and a C# Razor/MVC (.NET 5) application deployed separately all on the same domain. There is a reverse proxy setup to route requests for each to their own server. So www.somedomain.com/IdentityServer, www.somedomain.com/MVC and www.somedomain.com/api.
I am using Identity Server to authenticate and we can successfully do so without an issue. However when I try to call one of the API endpoints (which are decorated with the [Authorize] attribute) from the C# Razor/MVC application I get a 'Authorization failed! Given Policy has not been granted' error.
When I run the same endpoint that the C# Razor app consumes using swagger/postman (after I've been authorized and get a token) I have no problem returning returning valid results, so the issue seems to be related my authentication between the Razor app and Web API.
When I run these 3 tiers locally in Visual Studio (all with localhost but a different port #), it all works just fine.
Any thoughts or additional information needed to give me some ideas of what the issue may be? Thank you so much in advance for your help.
So we have a .Net Core 3.1 Web Api hosted on Service Fabric.
For some requests we use Http Get with a body (yes I know it's not pretty but it's not forbidden) because we want to retrieve some data and so Http Get is the verb to use accoding to REST api.
We made some test and on a "normal" web api without Service Framework it works fine to put a body on a Get Request, but then when we use this on our Api with service fabric we have a
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Reading the request body timed out due to data arriving too slowly. See MinRequestBodyDataRate.
I already try : opt.Limits.MinRequestBodyDataRate = null; in the UseKestrel
When we change the method from Get to Post it's works.
So I was wondering if there was something specials with Service Fabric (maybe with the reverse Proxy) that made our request fail?
Have anyone some clue on what is happening?
Thanks
Background
Our API allows users to upload large files, like PDFs, JPGs and PNGs. Recently we have experienced a ton of requests that times out when the server has been idle for some time. Our clients would experience 2 minutes of wait time and then receive a 500 error message.
We use Azure API Management to provide clients with documentation and access to the APIs.
Client -> API Management -> Web App
However, after looking at insight it is clear that the issue is between API Management and our Web App, which is where we have a SSL certificate set up.
The issue
The issue seems to be that sending a large POST request containing a SSL certificate to "wake" the API makes it deadlock. I've debugged the API using application insight as well, but it seems like the request is not received by any operation at all.
After debugging the issue with a brand new Web API project and Web App, I have narrowed it down to that the timeout only occurs if:
The server is configured for HTTPS only and/or Client Certificate Required.
I let the server be for 5-10 minutes before sending my first request.
My first request contains a large file, like a 2 MB PDF file.
I set up the following resources in order to debug the issue.
Web API
I created a brand new project, ASP.NET Web API, framework 4.6. I only added a simple files controller.
using System.Net;
using System.Net.Http;
using System.Web.Http;
namespace DebugCertificate.API.Controllers
{
public class FilesController : ApiController
{
public HttpResponseMessage Post()
{
// Success
return Request.CreateResponse(HttpStatusCode.OK, "Welcome to the POST files resource!");
}
public HttpResponseMessage Get()
{
// Success
return Request.CreateResponse(HttpStatusCode.OK, "Welcome to the GET files resource!");
}
}
}
Web App
I set up a brand new Azure Web App and configured it with the following settings.
Steps to reproduce the issue with Postman:
Wait 5-10 minutes.
Send a POST request to the /api/files resource containing a large file (2 MB in this case).
The timeout occur after 120 seconds.
As long as you only send large POST request, you can repeat step 2.
Notice that I don't even have to send a client certificate with this request for the issue to occur.
The issue will not occur
When require client certificate and HTTPS only is off.
When you send a GET /api/files request first and within 5-10 minutes send the same POST request described in step 2 above.
Possible leads
After diagnosing the Web App in Azure I found the errors that are generated by these requests. I have Googled this description but have not found any information that would fix my issues.
I found something that sounded similar, but this article sounds like it is between the client and API Management, which is not where we have the SSL certificate set up. Look for the green TIP box.
How to secure APIs using client certificate authentication in API Management
I also found this article containing a few ways to solve the issue, but "priming" the API with an additional request seems like a bit of a hassle.
HTTPS Client Certificate Request freezes when the Server is handling a large PUT/POST Request
Questions
Why is this happening?
Is there any workaround that does not involve "priming" the API? A simple Web.config setting maybe?
Let me now if more information is required!
Go to your domain under custom domains, click the on proxy domain name and then tick the negotiate client certificate option.
If you are using consumption tier then enable the requests client certificate option.
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates-for-clients
I have a WCF service which i host as a Windows Service. I need to support both Windows and NTLM authentication on the service endpoint.
I came across a MSDN page which explains exactly the same with .NET 4.5, here's the link:
http://msdn.microsoft.com/en-us/library/hh556235(v=vs.110).aspx
Going by this, I configured my service endpoint in code as explained in the self-hosted services section of the above link. But, when I test this doesn't work. I captured the traffic and observed that there's no HTTP 401 challenge sent by the service, instead, it directly fails with HTTP 400 Bad Request error. I believe that should have been a HTTP 401 challenge sent to client.
Did I miss anything here?
Well it is possible and I could make it work after 4 days of struggle, the errors HTTP Bad Request does not indicate the problem. But, As I added service metadata behavior with HttpGetEnabled it worked.
Also, ensure if you define ServiceAuthenticationBehavior you do mark the ClientCredentialType to InheritedFromHost. This would ensure the authentication schemes as indicated by the ServiceAuthenticationBahavior are applied.
Hope, this would save someone else's 4 days! :)
You can have multiple authentication schemes running within the same Windows service, but not at the same end point - that's not possible.
For instance, I can create and IIS or self-host a web service called NeedHelp that uses three kinds of authentication, and here are my endpoints:
http:/ /NeedHelp:8001/NoAuth
http:/ /NeedHelp:8002/WindowsAuth
http:/ /NeedHelp:8003/CertAuth
All of those can run under the same web service, all hosted by IIS or self hosted as a Windows service. But they all need separate port addresses.