I have set up an Azure Frontdoor Load Balancer with 2 backends, hosting an Angular app. When looking at the network traffic in the browser's developer tools, I see that only the first few requests for *.html and *.js files go to the loadbalancer. Beginning with the GET options request, all subsequent requests seem to go directly to the backend #2 (in red in the picture below):
This means, if the backend #2 goes down, the client gets 404 errors, and won't be automatically redirected to backend #1, unless the user reloads the browser window with F5.
I'm not sure how the Angular app gets the actual backend host's URL. I cannot see any header or cookie which would provide this information. The headers of the first request for login.html look like this - no sign of the backend URL anywhere:
My questions are
how does the client get the backend host's URL?
is there a way to define that ALL requests go through the loadbalancer?
Would that even be a good idea? Or is this the "intended behaviour", meaning that the user WILL see 404 errors and have to reload the page manually?
It the application that is doing it, not the azure front door. The app must be constructing the url based on where it is hosted and them making a request. The front door will set the host header same as the app service's hostname. In that case, the application would see it's request to come as if the user typed that in the browser. You would typically want to use custom hostname e.g. neonapp-dev.yourcompanyname.com. When you do that both app services and the front door would have the custom host configured. While configuring the front door, you would use this as a host header rather than the default which is app services host name. Then everything would work fine as the app would never see the app services name as host header.
More details https://learn.microsoft.com/en-us/azure/frontdoor/front-door-backend-pool#backend-host-header
Related
I have an app function in Azure that is behind a front door. The front door uses a custom domain which has a CNAME record setup with our DNS provider.
The app uses MS Authentication when you access it.
What happens is that when I access the URL of the front door (https://website.domain.com), it directs you to the log in page as expected, I log in and then get directed to the app. All good, but rather than displaying and being from the original URL, it pushes me to a azurewebsites.net URL. We are going to be doing API calls via front door and need the replies to be from the custom domain URL.
As a test, I set up another front door in the same with an app function without authentication and this behaves as expected (app function continues to use the custom domain from the front door).
I have tried to set a custom domain on the app - no dice.
I have tried changing the header in the back end of front door - this makes the access to the app stop completely.
I have tried adding post_login_redirect_url to the app configuration and pointing it to the custom domain URL - no dice.
There must be a way for this to work? Has anyone managed to successfully manage this? Thanks.
I have a problem configuring my Open Auth ID .net Core 2 application as an App Service behind a Web Application Firewall using a Path based routing.
My application is myapp.azurewebsites.net with a network restriction making it inaccessible from the public internet. I have deployed a WAF in the same VNET and allowed traffic between the WAF and App Service using a Path based route "/Admin*".
The effect is that https://myapp.azurewebsites.net is not internet accessible but https://myWAF/Admin is accessible and maps to the app service.
This setup works fine, but when I introduce Open ID auth to my .net core application the outgoing Location header includes its myapp.azurewebsites.net/signin-oidc as the reply URI.
This doesn't work because the host is not accessible from the internet. I have attempted several approaches;
I have added the WAF URL (https://myWAF/Admin/signin-oidc) in the application registration URL in Azure App Registrations to allow AAD to accept the modified URL (as legitimate
I have coded app.UseForwardedHeaders (forcing reuse of all X-Forwarded headers) in my startup.cs. This doesn't seem to have any affect on the Location header being sent by my App Service.I presume the WAF is sending X-Forwarded headers, but if it is, the Open Auth ID stack isn't using them.
I have coded a header rewrite in the WAF to replace the myapp.azurewebsites.net with the WAF URL. This does replace the URL correctly and allows the callback, but then fails with a Correllation Error (which seems to be a generic Open ID stack error meaning "the nonce does not match". Its possible that the nonce is predicated on the URL being called back to - which in my case changes due to the WAF redirection, but that's a guess).
It seems to me like I should be able to use the X-Forwarded headers in my app to get around the need to code up header re-writes in the WAF, but I can't find an example where this is used successfully to alter the Reply URI being sent out by Open ID.
My question it; is using the X-Forwarded header the correct approach to handling proxies in an OAuth context, or is header-rewriting in the WAF the correct approach ?
I have set
After much investigation I found the following;
WAF does not send the standard X-Forwarded-Host to App Services but sends X-Original-Host instead. Documented here https://feedback.azure.com/forums/217313-networking/suggestions/33657763-add-the-x-forwarded-host-header-to-application-gat
The ForwardedHeaderOptions that ASP.net Core 2 uses in its ForwardedHeaders middleware have an option to replace the expected and supported "X-Forwarded-Host" with an arbitrary other host header name. This behaviour can be triggered as follows to replace the use of the x-Forwarded-Host with the WAF specific X-Original-Host.
options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";
WAF does not pass the Path of the Path Based Route down the Http Header stack as expected in the PathBase header. This must be added to the Request Headers either in the WAF via a Header Rewrite, or inside the app as follows (in this case the apps Path Route is /Admin);
app.Use((context, next) =>
{
context.Request.PathBase = new PathString("/Admin");
return next();
});
I made a react add with node backend using the stripe express checkout form, and passing the source and other data to the backend to subscribe users, but on production it does not work.
I have it on an ubunutu vps, and the app is served with nginx as a reverse proxy of localhost. but it is not working, i also added ssl certificate to the domain but I am getting an error now that says:
Blocked loading mixed active content “http://localhost:8080/api”
on the server version in stripe test mode.
how can this be fixed?
In production it is required that you use SSL with Stripe. Your error is because you are trying to load or access http://localhost:8080/api from an originally https page. Stripe requires that all of your resources are loaded via https/SSL.
You also probably shouldn't be loading localhost in production. You should be using your actual hostname in production with https.
Let's say you load https://example.com/ in your browser. And you want to make a call to your backend server that is running on https://example.com/api. Instead of specifying localhost you can just change the URL to be /api and that will automatically append the domain name https://example.com to the request. This only works for the same domains. If it's separate domains you have to specify the domain name in your request.
I am working on web application that has angular 4 on frontend and WEB API on backend. This application is hosted on MS Azure and until now we didn't have any issues.
Currently we need to integrate with one payment provider. During payment user is redirected to his payment page, and if everything goes well user is redirected back to our web site. Beside the browser redirect (which may fail) payment provider supports server to server call (HTTP GET). In this way they make sure we get information about the transaction. The problem here is that instead of one call to our Web API backend we get always two calls. After checking the request origin IP addresses I concluded that there is two origins (one is payment provider address and another is IP located in USA, which I assume belongs to MS). This looks to me like a routing problem, but I am not very experienced at this.
Did anybody have similar problem on Azure while hosting web application ?
According to your decription, it seems that fails for cross domain request. Azure website is supposed to manage CORS for you.
I think you missed a handy Azure website blade: Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
Cross-Origin Resource Sharing (CORS) allows JavaScript code running in a browser on an external host to interact with your backend. Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
We have an app service which is an ASP.NET app in Azure. We have defined 200 OK response for / route. When we try to hit / endpoint from browser or Postman we get desired results.
But in Azure App Insights we notice GET / request every 5 min that is failing.
DNS Configuration
From the picture provided, you can see that default Azure route (qualitykitchen.azurewebsites.net) is still there as we haven't figure out a way to delete it.
404 Errors screenshot from Azure It is important to note that request that generates 404 is the default route for (qualitykitchen.azurewebsites.net) instead of the custom route that we setup via custom DNS which is (api-staging.qualitykitchen.co).
Because we’re have ‘Always On’ enabled we’re pretty sure the requests are simply Azure pinging the service to keep it alive. Unforunately it seems like it’s confused on which route to call.
Are we correct in assuming that the requests are coming from Azure? How can we direct Azure to make a call to our custom route?
Yes, that's correct, that's the AlwaysOn agent (check User-Agent in your telemetry).
Unforunately it seems like it’s confused on which route to call.
It's not, AlwaysOn agent always calls http://{sitename}.azurewebsites.net/, disregarding custom domains. It always calls / and you can't specify a custom URL.
Simply handle that domain as well and respond 200 OK back. You can not remove the default .azurewebsites.net binding.