I'll try to explain my problem the best that I can. I have a Flask app using blueprints with subdomains for redirecting to versions of the same site with different languages.
es.my_site -> spanish version.
en.my_site -> english version. and so on.
The app is working locally, defining:
application.config['SERVER_NAME'] = my_site.com:5000 in application.py
and adding 127.0.0.1 my_site.com:5000, 127.0.0.1 en.my_site.com:5000 and 127.0.0.1 es.my_site.com:5000 to /etc/hosts.
My problem starts when trying to deploy the app to aws beanstalk.
My first question is what to config in application.config['SERVER_NAME'], I've tried configuring the url that beanstalk gives me my_site-env.eba-******.us-west-2.elasticbeanstalk.com:5000, and this works, but only for routes that don't use blueprints.
When I try to access an url generated by the blueprint, the url_for() method is called multiple times until an error is thrown, each time adding the subdomain again to the url.
url_for() is called multiple times and redirect(url_for('endpoint')) never redirects to the correct endpoint.
Result of each successive call to url_for():
es.my_site-env.eba-******.us-west-2.elasticbeanstalk.com
es.es.my_site-env.eba-******.us-west-2.elasticbeanstalk.com
es.es.es.my_site-env.eba-******.us-west-2.elasticbeanstalk.com
es.es.es.es.my_site-env.eba-******.us-west-2.elasticbeanstalk.com
es.es.es.es.es.my_site-env.eba-******.us-west-2.elasticbeanstalk.com
This works fine locally, that's why I think this is related to a configuration in the Beanstalk server, my app configuration or something DNS related. But I'm not an expert in either Flask or AWS, so it could be something else.
Any help is really appreciated. Thank you.
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
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.
My name is Diego and this is my first question on the site. I'm Argentinian, so, sorry for my bad english.
I was introduced into Amazon Web Services (AWS) four months ago, and I worked with services like EC2, S3, Route53, IAM, etc.
Now, I have the next scenario:
An EC2 (1), with a website based on React (frontend) and Node.js (backend)
An EC2 (2), with a webapp based on React Native and Express.js
In Route53 I registered the domain.com pointed to the first EC2 (the website, on port 80), and the webapp is running on the second EC2, on port 3000.
After searching and read a lot a few days (I will let the links at the end of the post) I came here to solve the doubt.
The question is the following:
When I go to domain.com, I will come on the website, so, some paths like /home, /services, /ourworks, /team, etc. will be part of it. But... If the word that comes after the bar isn't it one of this, I need to send the user to the second EC2 on port 3000, that is to say, the webapp. After that, the webapp will know what to do with the route.
So...
What is the best way to route this scenario?
I have read about:
-Use an .htaccess to routing paths and ports. This was fine in the last scenario, when the website was a Wordpress site, but now the website is based on React and Nodejs, so, we not use Apache anymore, so this solution is useless for me.
-Use the routing of the Application Load Balancer (ALB). This is fine, but the price of this service is so expensive, so I can't use this by now.
-Use the routing of the API Gateway service, but after read a lot, I can't find an official documentation of how to route with API Gateway to an EC2 server directly. All of the documentation speak about APIs REST or APIs with WebSockets, with DynamoDB or Lambda service. None of that is useful for me. I can't understand how to use API Gateway for my purpouse.
-Use NGINX on the EC2 which domain.com points, and route paths from this point. this's maybe a good solution, but I never worked with this software.
So, i'm so confused right now. Can anybody tell me which is the best solution for my problem, and why? I will really appreciate that.
The links I have read these days:
-Redirecting with htaccess to nodejs app (I don't know if using Apache is a good solution)
-https://www.reddit.com/r/aws/comments/71lz5v/applications_routing_based_on_url/ (This is a good post on Reddit)
-https://aws.amazon.com/es/blogs/aws/new-host-based-routing-support-for-aws-application-load-balancers/ (Use ALB and spend a lot of money, haha)
-AWS Route 53 - Domain name route to different ports of an Application load balancer (More of ALB, but this is so interesting)
-https://forums.aws.amazon.com/thread.jspa?threadID=152643 (This is the scenario most similar to mine, but poor man, never got answer)
Well, thanks to all for read and, if I violated any rule on the forum, please forgive me. Goodbye! :)
greetings from Colombia =)
My best advice here is to put Nginx upfront on those EC2 instances and use it as a proxy or load balancer, the best approach would be the one where you could even run multiple processes of your apps in the same EC2 instance providing a better scalability and balance the load using Nginx, here are two articles to accomplish this setup:
https://nodesource.com/blog/running-your-node-js-app-with-systemd-part-1/
https://nodesource.com/blog/running-your-node-js-app-with-systemd-part-2/
There are other options with more complex approaches as the ones you are describing, but I think this one is the simplest and cheapest.
I am making a web app with node.js using google app engine.
I want to redirect https://MY_PROJECT_ID.appspot.com to mycustome domain. I followed this maual but does not work. What is problem?
https://cloud.google.com/appengine/docs/flexible/nodejs/how-requests-are-routed#routing_with_a_dispatch_file
dispatch.yaml
dispatch:
- url: 'fermi.me/' //my custom domain
service: default
console
gcloud app deploy dispatch.yaml
Configurations to update:
descriptor: [./nodejs-getting-started/2-structured-data/dispatch.yaml]
type: [routing rules]
target project: [XXXXXXX]
Do you want to continue (Y/n)? Y
Updating config [dispatch]...done.
Even though, dispatch.yaml is successfully deployed, if I executed 'app deploy', Redirection does not work. I already registered domain in Google cloud, and static websites worked.
I found the fundamental problem and it solved.
I already connected to static website with bucket.
https://cloud.google.com/storage/docs/hosting-static-website
There is a error in web-console in App-Engine domains setting.(Message: "Domain is already mapped to a project in google cloud platform". There is a critical error in this maunal.
https://cloud.google.com/appengine/docs/standard/python/mapping-custom-domains
The sample error message. It only appears when you already connect storage static website to domains.
error : domain is already mapped to a project in google cloud platform
You can use command-line tool with gcloud beta. Webconsole makes error but commandline works. After you mapped domain, you can now use webconsole. You should add cnames as the maunal above(mapping domains) explains There is a guide.
https://stackoverflow.com/a/46780534/9049333
The dispatch file is only used to direct a request already reaching your app to the appropriate service/module. If the request doesn't match any dispatch.yaml rules it is automatically directed to the default service (making your rule redundant, BTW).
The dispatch file does NOT redirect a request to another domain (or anywhere back outside your app, really). So you're on the wrong track at this point.
You need to take care of such redirection in your application. Possibly relevant starting points for that:
Disable default domain https://[project-id].appspot.com of Node JS on Google App Engine
HTTP to HTTPS redirection on App Engine
I am running a web application is AWS. I have a load balanced environment set up in Elastic Beanstalk and i have attached a certificate to that for HTTPS.
When i access the homepage URL, HTTPS works absolutely fine. The issue i have is when i add something to the URL such as /login then HTTPS just refuses to work and only HTTP will work.
It seems that it worked fine when it was using the sample application. However when i have uploaded my files to the environment it has the issue.
I am running a FuelPHP application. Does anyone know a fix for this, is it to do with my htaccess?
For anyone with a similar issue, it was Fuel PHP which was the issue. There is a setting under fuel/app/config/config.php to allow HTTP requests. Uncomment the following line:
'allow_x_headers' => true,