I am using two application parts that deployed on: AWS Beanstalk and Netlify.
Java-based part is deployed on AWS and available on http protocol.
Angular based is deployed on Netlify and available on https protocol.
The error occurs when sending a request to AWS:
Mixed Content: The page at 'https://some-url.netlify.com/' was loaded over
HTTPS, but requested an insecure XMLHttpRequest endpoint
'http://some-url.elasticbeanstalk.com/api/getAppSettings'. This request has
been blocked; the content must be served over HTTPS.
I need to do it working for learning purposes only, so try to make Netlify working under Http.
Is it possible to change the protocol to simple http on Netlify?
The adding SSL certificate to Elastic Beanstalk is complicated, unclear and takes too much time
AFAIK, netlify doesn't allow you to access website over HTTP, as they force redirect to HTTPS by default, as mentioned here. But its really easy to have HTTPS on AWS - your elastic beanstalk instances are served with HTTPS by default using an AWS owner certificate, and you can link your custom domain certificate if you have a custom domain, very easily from AWS Certificate Manager.
You can create a netlify.toml file and do some redirect tweaking, as mentioned here.
Creating and configuring a _redirects file in the root of your build folder(or in your public folder if using an SPA like React) might help with this. For your example, the _redirects file would look something like this:
/api/* http://some-url.elasticbeanstalk.com/api/:splat 200
Then rather than call endpoints like this:
fetch(`http://some-url.elasticbeanstalk.com/api/getAppSettings`)
You would need to make your API calls in this format:
fetch(`/api/getAppSettings`) // 'it reads /api/ because of how we configured our _redirects file'
You can read more on how to make netlify proxying here
Related
I am building an app using firebase that needs to load an external webpage under an internal url i.e. when you go to myapp.com/edit it requests the content from someotherapp.com/edit and renders it in the browser without redirecting. I've tried using firebase hosting rewrites, but you can only rewrite to an internal url or a cloud function.
What you're describing cannot be accomplished with rewrites, as those (as you say) can only rewrite to a location on the same server.
A redirect would allow you to redirect to a different server, but that new URL is then sent to the browser.
The only alternative option is to use Cloud Functions or Cloud Run to capture all requests, read from the remote server in that code, and then send that back to the client with a suitable caching interval.
I tried deploying a Heroku web app with my Flask backend (not on Heroku, actually on GCP) and got the following message in my browser's dev console:
Mixed Content: The page at 'https://x.herokuapp.com/' was loaded over
HTTPS, but requested an insecure XMLHttpRequest endpoint
'http://x:5000/endpoint'. This request has been blocked; the content
must be served over HTTPS.
I have little experience with serving and SSL, but the first temptation here would be to find a way to make Heroku okay with using http endpoints. And I'd love to avoid setting up SSL if possible.
What are my options from here?
Thanks!
In the end I realised that by applying my own http domain to the project (rather than using Heroku's domain), I am able to avoid the issue.
Then with http on the frontend, I was able to call http endpoints from my GCP server.
We created static one page WEB application that uses external API for authentication and data.
We set dedicated URL space prefixed with /api to solve cross domain restrictions with reverse proxy. Proxying works fine with Ngnix, Apache on local setup but I can't find proxying support in Firebase Hosting: https://firebase.google.com/docs/hosting/url-redirects-rewrites
There is Function offer that can run node runtime up to 1 minute per call. Can't it be used to implements reverse proxy?
UPDATE We ended with Heroku offering. It hosts our static JS/CSS assets via WEB server (internal detail of a particular cloud provider) and same WEB server is user for proxing API calls via defined extension point, mapped to URL root like /api.
This way JS application is written to issue API calls to URL without schema / host / port, it doesn't matter if you run it on localhost (development) or in cloud env (prod)!
I have an ASP.net MVC app running on Azure App Service ... I've searched for the answer, but have not found it ... my app seems to always force HTTPS redirect, no matter what. All the docs say it should serve content via HTTP by default, but it does not. Most everyone has the opposite problem of needing to redirect HTTP to HTTPS.
I need Azure App Service to do the following:
1) Serve static Default.htm page via HTTP, without redirecting to HTTPS
My app has a custom domain and no SSL for the custom domain. I want the URL http://example.com/Default.htm to serve the static page, not redirect to HTTPS to serve the static page. I will use azurewebsites domain when I want users to be in HTTPS. I want to use my custom domain name to serve a static home page for users arriving at my site.
As far as I can determine, I do not have any app extensions installed (such s https redirect extension), or anything in web.config to force https, or any RequireHTTPS attributes ... can anyone explain why plain old regular boring HTTP doesn't work here?
Thanks
I have a https site say with url www.example.com. On this server, I've an application which is decoupled in front-end and back-end. The front-end is a gwt application and the back-end is a REST interface.
To call the rest interface, the front-end uses https, say with a url like https://www.example.com/api
however, when I'm trying to call the front-end using http://www.example.com, it is not making the call to rest interface when i'm using https://www.example.com, it is ok. Can someone explain the reason of this problem??
https://www.example.com and http://www.example.com are different URIs and nothing requires that a web server serve up the same content for both. Presumably your server isn't configured to do so.