I'm trying to setup empty azure web app to be reverse proxy following exact same steps as described here: https://tomssl.com/2015/06/15/create-your-own-free-reverse-proxy-with-azure-web-apps/. First of all it seems that allowedservervariables can not be transformed, it is set to deny in application.config file. When i remove them i just get 404 not found when i try to access my webapp (HTTP Error 404.4 - Not Found
The resource you are looking for does not have a handler associated with it.).
Anyone have some suggestions?
Cheers
You should try Azure Function Proxies instead
https://markheath.net/post/azure-functions-v2-proxies
A developer can create an Azure Function Proxy within the same UI as a Function App. Within the configuration, a developer will be asked to provide a Route template, identify which HTTP methods are allowed and provide a Backend URL where the HTTP request will be routed to. Backend URLs do not need to be static as you can dynamically set the URL based on content within the request or from your application settings.
Related
We have a web app in Azure sitting behind a V2WAF Application Gateway. This is all private so the WAF uses a private frontend IP address and a certificate generated with openssl. The backend uses the azurewebsites.net domain so the backend app doesn't have any custom domains and therefore certificates assigned.
The WAF is configured with rewrite rules as per microsoft docs.
If
http header
response header
common header location
= pattern (https?)://.azurewebsites.net(.)$
then
response header
set common header location
Header value {http_resp_Location_1}://portal.uat.xxxxxxx.internal{http_resp_Location_2}
The result from this is a 404 not found.
I found this on github which seems to match the issue
https://github.com/AzureAD/microsoft-identity-web/issues/1199
Has anybody come across this and found a fix I can apply to the WAF?
The domain being used for the WAF frontend is.internal and can't be added as a custom domain into the webapp, not my choice but the person telling me this config works has said it's worked before.
Thanks
I've tried various things, but nothing has worked so far. I'm not a developer so need to be able to get this working just using the App Gateway.
I think I need a custom domain that can be verified and a matching SSL cert on the app service but the "architect" is telling me this works. I can't figure out a way of doing it.
We are trying to get Azure app proxy to work and are running into CORS issues. We are using custom domains with split brain deployment.
I have read through: Azure Application Proxy CORs
and am currently on step 4 to just rewrite cors to work with out the wildcard below
var cors = new EnableCorsAttribute("*", "*", "*");
config.EnableCors(cors);
Our web application has a frontend server hosted on IIS: https://frontend.company.com with the internal and external urls mapped to be the same urls as behind our company firewall.
We also have a backend server located on premises hosted on IIS and located at https://backend.company.com
We have set up two applications in app proxy to point to the respective servers where the internal and external match the urls we are using internally to the company.
I have tried var cors = new EnableCorsAttribute("https://backend.company.com", "*", "*")
and still get the cors issue. One thing I noticed is We are not getting the Response headers when going through Azure Proxy. Here is a picture of what it looks like internally and you can see access-control-allow-origin is set to *
The end goal is to be able to access this application externally. I can get the frontend to pull up html fine, and I can go directly to the swagger pages on the backend side just fine, but the two cannot communicate cross origin.
Below is what we see when accessing externally through app proxy:
We have tried to set web.config values, and remove values with pretty much every stack overflow article we can find.
Question is Does Azure or Azure App Proxy have any settings around allowing Access-Control-Allow-Origin settings to flow through? I dont have access to App Proxy, and am having to work with our cloud team to try different things. We have tried every combination of the Translate URLS mentioned here https://stackoverflow.com/a/60560675/1879992
Below is what we see externally and has the request headers missing
We have also read the official document and whitelisted our urls with the same response.
If I disable the chrome setting related to CORs the app comes up fine.
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
I'm configuring Azure Application Gateway Url based routing for my two back-end pools and it is not working.
My default routing configuration is pointing to b1 end point and it is reachable by blabla.cloudapp.azure.com
When I add additional route path /b1/* I cannot access my back-end pool via blabla.cloudapp.azure.com/b1/. I get 404 page not found response.
Can anyone please help me to understand what is wrong with my configuration?
Azure Application Gateway URL Based routing will route different requests to different groups of servers (backend pools) based upon the URL of the request. Once the request is sent to a VM, it is received and treated like a normal web request. If the URL you are accessing is a Valid web URL for the web server that is receiving the request, then it will return a proper response.
The fact that you are getting a 404 error means that your web servers are receiving the request, but not finding anything at the requested location. One way you can troubleshoot this is to log onto the VM that should be receiving the request and trying the request in a browser replacing blabla.cloudapp.azure.com/with localhost/.
In the example you posted, you would need a folder from within your web directory called "b1" for the URL you specified to be a valid request.
You can use a Path-Based Rule to specify the default backend pool, as well as specific URL paths that should be sent to other backend pools. Here is an example of how to configure a Azure Application Gateway with URL based routing in the Portal.
I have an Azure Web app that runs Web API 2 and it provides an access to Azure blobs. I see from logs, that there are some user requests that are denied by the app with code 403 without even getting to the controller itself (there are no corresponding logs). The only special thing about those requests I remarked, is the client IP that has a pattern of 192.168.. I checked the block list of the app and it's empty. Has someone an idea what can be wrong?
Figured it out. When request passes through proxy (some of them maybe), its headers changes (the key case) and the comparison in the code is not working.