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.
Related
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
I have a Meteor app that mysteriously redirects to the registered root url, when a new custom domain with different tld is registered and tried to be accessed. This happens only with custom domains… Please note that it is the root url that it’s redirected to, not the …herokuapp.com url…
Some other, perhaps important, detail is that this happens quite intermittently; meaning it doesn't always happen and mostly happens if the client has previously loaded the root url or another custom url pointing to the same app.
What could be the reason and how to overcome that?
I can verify that the reason was not at my DNS configuration level, nor at any Heroku configuration I have done. But perhaps I need to do further?
I do know that this has to do with different top-level domains and how servers act toward that... Some of them like .app require SSL to work and so on, and that can be weird sometimes... But some others like .com and .market also redirect to the root url when registered as custom url and tried to be loaded in the browser...
So how to overcome the issue and have the same app running in different domains without mysterious/unwanted redirects??
The reason was indeed due to the force-ssl package from the core Meteor.
The package redirects to the Meteor.absoluteUrl() if the connection isn't registered securely (HTTPS/SSL). Therefore the problem have appeared.
I'm currently building a URL shortener and am using React for its frontend. It is where my domain (let's say example.com) is linked to using Firebase Hosting.
I'm in a bit of a struggle trying to figure out the redirection part of the service, as I want this redirection to be "HTTP native"; it should not require JS to redirect, just a plain 301 redirection.
Shortened URLs look like this: example.com/go/:linkId.
When a user clicks on a shortened link, My server should get the request, find out what URL is linked to the shortened URL's id, and redirect to the original.
Since I don't want to involve JS, I tried to use the redirects setting in firebase.json. At first, it looked promising just to use:
"redirects": [
{
"source": "/go/:linkId",
"destination": "<SERVER_URL>/go/:linkId"
}
]
Two issues with this approach:
It won't work on localhost, as (AFAIK) firebase.json isn't being taken into consideration when running Webpack dev server.
Anyway, there is a different server URL for development and production environments. I don't want to hard-code the URL since it won't let me separate between them.
I was thinking about redirecting to a go.js file or something that will live in the dist folder with index.html, but It won't be resolved a node.js file.
If you have any idea how to solve this, I'd be glad to hear.
Thanks!
Redirects will work locally when you use the Firebase CLI, i.e. by running firebase serve. If you need to preprocess your source to get the final distribution, you do that locally, and then call firebase serve on the output of that preprocessing step.
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 have two apps - One is the public face of the application, and the other is the app itself. I'd like to set up heroku to serve one app (the public site one) to www., and serve up a different app *.domain
Is this possible?
not with Heroku and multiple applications.
If you already have www.domain setup when you try to add the wildcard is suspect it wouldn't let you because the wildcard would also match attempts to www.domain and there's no way to set a priority.
I have apps like you talk of on Heroku and have them all the same codebase and then work out which site should load based off the requested url