Update
I have found, that the configuration is "correct", in that the application gateway properly routes to the correct backend when using the "/payment" path. On the app in question however, the path is still "/payment" which obviously does not work. I know I can circumvent this by using Override Backend Path to "/", but then, as said, the app does not load any CSS / JS files because it looks on the root of the host (I think)
I have a setup going with Azure Application Gateway for a project I am working on currently.
Setup
The basic setup goes like this:
Public IP --> Appliction Gateway --> Private Endpoints --> WebApps.
I have enabled multi-site hosting, have given an Azure domain (.cloudapp.azure.com) and have enabled path based routing.
So for example mydomain.germanywestcentral.cloudapp.azure.com/payment will route to a certain backend.
Issue
The issue is, while the HTML is loading just fine, all the CSS/JS is not looking at
"mydomain.germanywestcentral.cloudapp.azure.com/payment/site/style.css"
but at
"mydomain.germanywestcentral.cloudapp.azure.com/site/style.css"
I already googled for hours how to solve this issue but to no avail. I realize Azuer is one of the lesser used clouds as of now, but hopefully someone here can, at least in concept, explain what is happening and what needs to be done. Any pointers are helpful here :)
Disclaimer
I am rather new to the whole networking topic and Azure, so I am not sure how to solve this issue. How do I tell the app to not look at the root, but at the /payment. If I go to "mydomain.germanywestcentral.cloudapp.azure.com/site/style.css" it loads the file just fine.
Note
One thing: In order for any of this to work, I had to set "Override Backend Path" to "/", which is probably what is causing the issue.
However, if I turn this off, it does not load anything, and instead fails loading the site altogether.
Images of the settings
HTTP Setting for Payment Backend
Listener Configuration
Rule Configuration
Related
I am trying to setup one parent domain (app.mydomain.com) for front for 2 web apps in the backend.
mail.mydomain.com and module.mydomain.com. I have implement path based routing. I need to routing to work so
app.mydomain.com/* points module1.mydomain.com
app.mydomain.com/module2/* points module2.mydomain.com/
Routing seems to work, however when browsing module2, it css and js are not loaded and the site doesnt work. accessing module2 directly works normally.
Have you routing rules to change your URL?
Since you are using App Gateway, the URL that your backend is seeing is (app.mydomain.com) instead of module2.mydomain.com.
So, maybe when you’re using the AppGateway, your backend is looking for a CSS into the wrong path…
We are using azure application gateway to route requests from host/client to the specific client app (.NET Core). This way client1 is routed to server1/client1 and client2 is routed to server2/client2 and so on. We are using URL path map to resolve the exact server for each client.
Application gateway has a limitation in 100 paths in URL Path map per listener. This forces us to keep the number of client applications low.
Recently we have rewritten our application to support multiple tenants. So now we can process multiple clients' requests using a single app. Our new routing looks like server/app/client. Still, we want to keep end-clients URLs in the same way as those are: host/client
My idea was next: Use Application gateway rewrite set, and on request, replace URL path values from /client to /app/client; But it seems that no matter what I set into those rules I do I keep getting the same response. It looks to me that rewrite rules are simply ignored. Even the basic one that does not contain any if logic.
e.g.:
-
So my question is whether it is possible to update request URL before application gateway rules are applied?
Will be really glad to get some help here.
Don't know if you solved your problem but I had exactly the same !
It looks like Microsoft made some changes few days ago on Application Gateway. And now it works ! But I had to delete my Application Gateway and create it again from scratch.
Hope this will help
Denis
Disclaimer: I would ask this using either a.) some sort of support system on Netlify, b.) on a Netlify live chat session or c.) via their support community but a.) they don't let you, b.) they don't have one and c.) you can't currently create accounts or authorize from Netlify itself. (Seems like as an organisation, they don't really understand what would really nudge you into making you pay for a service).
Anyways, I am having an issue with deploying an Vue.js SPA with VueRouter via a netlify.toml configuration. The issue is, all internal routing is not being handled by the SPA. My solution has always been to stick a netlify.toml config file in the root of the repository that I am deploying from, with the following:
# The following redirect is intended for use with most SPAs that handle routing internally.
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
Yet, every internal route I visit gives me:
The exact same repo, but deployed on my personal plan 4 months ago (which has the same netlify.toml config in the same location) works fine. The application is also working on the current deployment branch locally. The routing is not broken. Has anyone else suffered with this inconsistent approach to redirects with Netlify?
So, my specific fix was to do the following:
Add a _redirects file to the public directory of my Vue application, then:
# The following redirect is intended for use with most SPAs that handle routing internally.
/* /index.html 200
Inside that file.
So for me, netlify.toml configuration for redirects is stil broken.
I am seeing exactly this behaviour as well. The netlify.toml contains:
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
But doesn't work. The deployment summary even shows that netlify didn't pick up the redirect config at all:
No redirect rules processed
This deploy did not include any redirect rules. Learn more about redirects.
I just faced this issue like 2hrs ago from now, but the netlify.toml is working fine for me. Make sure you have set the public directory in your netlify setting to '/' (exactly where your netlifly.toml resides) instead of blank or anything else.
I want to use a reverse proxy to point one of my endpoints to a resource that's hosted elsewhere. My primary server (where everything else is hosted) is in an Azure Web App and is otherwise working perfectly.
I've been using this seemingly failproof article along with the other links mentioned at the bottom of it: https://blogs.msdn.microsoft.com/zhiliang_xus_blog/2016/01/19/build-a-google-reverse-proxy-site-on-azure-web-app-in-less-than-3-minutes/
As a baseline, I used a Web App with no additional code and confirmed that the reverse proxy works. This was done by manually creating/editing the web.config file and applicationHost.xdt file then restarting the server.
I've tried 3 separate approaches (all on clean, new web apps) all of which are failing for me:
Push my code, confirm it works, then follow the reverse proxy steps manually
Follow the steps manually, confirm reverse proxy works, then push my code
Put the reverse proxy files into my codebase and push everything at the same time
None of these 3 approaches are working. Is this a bug in Azure? How can I try to figure this out?
Post XML Transformation (XDT), have you restarted the site?
I would suggest you to take a look at this blog from Ruslan:
http://ruslany.net/2014/05/using-azure-web-site-as-a-reverse-proxy/
It talks about using a Site extension. It implements the reverse proxy and it does the XDT transformation for you.
If the above is setup correctly, then there is something wrong with the URL Rewrite rules. I would recommend you to enable Failed Request Tracing and debug this further.
The link/way you posted used URL Rewrite to implement a reverse proxy. I tested it and it worked fine with my empty web application. After published a web application to the Azure Web App(For example, an ASP.NET MVC web application), the URL Rewrite stopped working. The reason is that all the requests to your web application are routed by ASP.NET route module.
To enable URL Rewrite for some URLs, we need to disable ASP.NET route for these URLs. For example, if you want to rewrite all the requests with "product/xxx" format to another site. You could add following code to RouteConfig.cs file.
routes.Ignore("product/{action}");
The problem in this specific case was the location of my web.config file.
It needs to be in the root directory of the application which, in my case, was not site\wwwroot. My code was being generated and copied into site\wwwroot\dist. Putting the config file in that directory fixed the problem.
Additionally, there are logs that can be enabled to get some insight as to what's going on: https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-enable-diagnostic-log
I'm moving from Apache on Linux to Azure Web Apps and I have a specific url (mysite.com/blog and everything under it) that is configured with a reverse proxy so the end user doesn't know that the content is actually coming from another service.
I'm sure I can do this within Web Apps (which runs on IIS) but I can't find any documentation on how to do this. As a backup I'm open to putting another service in front of my Web App.
How can I accomplish this in Azure?
Update: I did try using another service - Functions. My architecture looks like this:
This works in production but I'm hitting snags in development. /blog may or may not work depending on the entry point. In prod, our DNS will be configured so mysite.com points to mysite-proxy.azurewebsites.net and, therefore, any URI the user hits will work. In dev, however, we may want to browse to hit /blog from the Traffic Manager which will route us to /blog on the webapp which doesn't exist. Same problem, of course, if we go to /blog directly on the webapp. I tried to show these examples on the right side of the diagram.
I would like to find a solution so the webapp itself can handle the /blog proxying and then we can determine whether it's worth the speed and cost tradeoff compared to the existing solution.
You might want to checkout Azure Functions Proxies: https://learn.microsoft.com/en-us/azure/azure-functions/functions-proxies
Sounds like you want an Application Gateway (caution, costs like $15/day)
The AGW can have multiple listeners against multiple hostnames, including path-based routing.
You will want to add two backends, one for the /blog endpoint and one for the non-/blog stuff. The backends just take the IP or FQDN of the target resource, in this case you will have:
blogBackend: myblog.com
defaultBackend: myWebapp.azurewebsites.net
Then you need to add listeners for your public-facing domain, it would be like:
myHttpListener: port 80, hostname=mywebsite.net
myHttpsListener: port 443, hostname=mywebsite.net
Then you need an HTTP setting
myHttpSetting: protocol=HTTPS, port=443, useWellKnownCACert=Yes, HostnameOverride=Yes,pick from backend target
Then you need rules, one for http=>https redirect, and the other for handling the pathing
myRedirectRule: type=basic, listener=myHttpListener, backendtargettype=redirection, targettype=listener, target=myHttpsListener
myRoutingRule: type=path-based, listener=myHttpsListener, targettype=backendpool, target=defaultBackend, httpSetting=myHttpSetting, pathRules=
path=/* name=root backendpool=defaultBackend
path=/blog name=blog backendpool=blogBackend
You can create additional http settings and assign them to the path rules to change the behaviour of the reverse proxy. For example, you can have the user's URL be https://mywebsite.net/blog, but have the path stripped on the request to the blog so the request looks like myblog.com instead of myblog.com/blog
There's a lot of tiny parts, but the app gateways can handle multiple applications at scale. Biggest thing is to watch out for the cost since this is more of an enterprise solution.