I try to set up two different services under the same NGINX in this way:
When I hit /discovery/ from the browser, I see the result HTML page but the browser cannot load some resources that are in another directory:
So the browser request for /eureka/css/wro.css instead of /discovery/eureka/css/wro.css because, seems that NGINX does not translate properly the URLs in the HTML page.
In the source HTML, everything seems correct:
Is there any specific configuration that I miss in NGINX?
Related
I am trying to setup a URL rewrite in my next.config.js pointing a path to another subdomain e.g.
localhost:3010/xyz shows localhost:3021/foo/baz/bar
Both are separate NEXT services.
However when trying it just between localhost ports localhost:3010/xyz shows a blank page, if I change the rewrite to look point to our production environment, so:
localhost:3010/xyz shows https://example.com/foo/baz/bar
the page renders but none of the JS or images are loaded.
I see in my Console:
So it looks like it is looking for the JS on the localhost, not the production environment.
I have disabled all security headers but it made no difference
I have worked IIS site which has worked in HTTPS. Something break and now when i try to get it in https site looks like that without CSS styles. I see in source and CSS and JS files try to open as http (which get 404 error when I try to open it), but when i try to open it via https everything work. How to "force" these to open these files via https? URL rewrite rule, but how?
Thanks for help
This what you experiencing is "mixed content blocking". It occures when you reach website via https but some elements are via http.
To resolve the problem you should configure http to https redirection.
You can find 'how to' here: https://www.ssl.com/how-to/redirect-http-to-https-with-windows-iis-10/
Also make sure that you don't hardcoded links to application elements via http in app code (if yes then change to https).
How can we use github pages embedded in an iframe correctly?
I've hosted a website in firebase and it is using a custom domain over https, for example, https://www.example.com.
This website uses react and other things, but for one route (the landing page one) I would like to use a static page hosted on github, for example https://example.github.io/page. So, to achieve this I've created an iframe inside the route https://www.example.com/page.
The problem is I've been receiving the following error:
Mixed Content: The page at 'https://www.example.com/page' was loaded
over HTTPS, but requested an insecure resource
'http://example.github.io/page/'. This request has been blocked; the
content must be served over HTTPS.
The strange thing is the iframe looks correctly:
<iframe title="Page" src="https://example.github.io/page">unwanted text</iframe>
It is already using https, but looks like this is being ignored.
I already tried to use this meta <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">, close the iframe with </iframe> and add an unwanted text inside the iframe.
Can we solve this?
If you carefully examine your HTML code and the error message, you'll notice a slight difference in URLs besides the protocol part:
https://example.github.io/page - in the iframe src tag
http://example.github.io/page/ - in the error message
The reason could be that the URL https://example.github.io/page returns a redirect to the "canonical" version with the trailing slash (/page/), but a redirect URL must be a full URL, and the server for some reason isn't including the actual protocol in the redirect URL, always using http:// instead. That could be due to configuration or coding at the server side (see also github issue #289).
As a workaround, use a URL that doesn't trigger the canonicalization redirect, i.e. https://example.github.io/page/.
My sites run off a subdomain (yyy.example.com), but I'm required to include CSS files from the main domain (example.com). We run a CMS that doesn't let me do any server-side stuff during the preview stage, so I'm stuck sending a page over https that includes a CSS import to http. All my IE users get a mixed content warning because of this.
Is there any client side way for me to prevent this, other than maintaining separate security settings for the domain on every client machine?
Make use of protocol-relative URL's in the CSS links.
Thus so
<link rel="stylesheet" type="text/css" href="//example.com/style.css">
instead of
<link rel="stylesheet" type="text/css" href="http://example.com/style.css">
It will automatically pick the protocol of the parent request, which should work fine for HTTPS as well.
As far as I know, there's no way to avoid that warning. It's there particularly for this purpose: alert you to the fact that even though you believe your page is SSL-encrypted, some of its content isn't. You'll either need to serve the original page over HTTP (not recommended), or serve the CSS file over HTTPS.
There is one proviso .. IE downloads the resources twice it seems.
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
When you say that you cannot do "server-side" stuff, do you mean that you cannot touch your CMS, or that you do not have root access to your HTTP server?
Because if you do have access to your HTTP server, you could set up a very simple reverse proxy (with mod_proxy if you are using Apache). This would allow you to use relative paths in your HTML, while the HTTP server would be acting as a proxy to any "remote" location. In fact this technique can also be used to mitigate some cross-site scripting issues.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically use it as follows:
ProxyPass /css/ http://example.com/css_dir/
In this case, the browser would be requesting https://yyy.example.com/css/main.css but the server would serve this by acting as a proxy to http://example.com/css_dir/main.css. It will not raise the browser warning, and works fine with SSL.
I am using a master page layout etc, so all the pages have some parts of it coming from one master page or another.
Now, checkout is one of these pages, and it needs to be secure. In my master page, I am using relative path to images and Url's, and these images end up with "http". I thought that if I am using relative path, my master page AND css file automatically use https instead of http if the page is secure? Apparently it does not, when I right click on an image, it still has "http" instead of "https" ans same goes for URL path.
Check out this great article by Ned Batchelder which shows schema relative URLs:
<img src='//fast.cdn.net/pix/smiley.jpg' />
When the images come back as http are you checking this from your local dev or production? I thought I had this problem before but then realized my dev environment was always http and that the relative path would work in production because there it would be https.