I have a nodejs app with express as backend which is running on localhost. I have subdomains associated with it like user1.localhost. These subdomains are opening in Chrome but Firefox throws Server Not Found error.
Does Firefox needs some configuration to allow subdomains?
I think the reason is that Chrome resolves *.localhost to localhost internally and other browsers request DNS server for subdomain.localhost (which obviously fails). You can use hosts files to make it work for them.
The reason Chrome does this is security reasons, you can read more about it here.
Related
HTTPS conflicts with HTTP
I make my first full-stack project on React and NODEjs and deployed it on netlify.
My backend server runs on HTTP localhost.
And here is a problem:
My app works on my Mac in Chrome but doesn't work properly on other browsers and computers.
Other computers can download index.js (display sign-up and sign-in pages) and it seems there is no problem with CORS but authentication doesn't work.
Safari logs mistakes:
[blocked] The page at https://MYAPP.netlify.appwas not allowed to display insecure content from http://localhost:3500/register.
Not allowed to request resource
XMLHttpRequest cannot load http://localhost:3500/register due to access control checks.
I don't understand why the app works on my MAC but
doesn't on other computers and can't find an answer on how to solve this HTTPS - HTTP conflict
I have tried to find a problem in CORS but it looks like CORS is ok. Also, I tried rewriting the server with HTPPS but it didn't work.
I've never worked with Netlify, so I could be wrong, but I suspect your problem isn't directly related to Netlify.
The Safari error message indicates that your frontend is trying to talk directly to localhost. localhost is an alias for "the computer that is making the connection attempt" under normal circumstances. This means that when someone runs your frontend, the browser tries to talk to the backend running on the same computer that the browser is running on.
This works on your computer in Chrome because you probably have the backend running on your computer for testing. Safari is only complaining that the frontend was loaded via HTTPS but is trying to talk to non-HTTPS servers. It is not stating that it can't talk to the backend, it's stating that it won't even try.
If I'm right and you shut down the back end on your computer, it will start to fail on your computer as well, even on Chrome.
If this is the problem, the solution can be one of two things: You can either run the backend somewhere where it has a domain name/ip address that everyone can connect to, or you need to run a proxy for your backend somewhere where it also meets those conditions, and has a way to pass the request on to where your full backend does run.
You need to find a way to run your backend somewhere other than your own computer or have something somewhere else proxy requests to your computer which then gets relayed to the localhost address. How you go about that will depend on things you didn't specify in the original question.
I have a website hosted via S3 and served through Cloudfront. The web requests I see coming from my domain are all served over http1.1 and not http2, even though it is checked (by default!). Are there additional tasks I need to do to be able to see my content being served using http2?
I can see in the network tab in Chrome that some assets are being loaded via http2 (resources that do not come from my Cloudfront) but everything being loaded from my Cloudfront is http1.1
Update 2
It seems as though other users are seeing my site loaded over http2 correctly, and I tried using Firefox, and see the same results. So this is a Chrome issue, not a Cloudfront issue.
This was not an issue with Cloudfront, instead I think it was combination of antivirus, network firewall/VPN, and Chrome caching. I turned off all VPN, antivirus, cleared cache in Chrome, restarted my computer and Bam! Page loads over HTTP2
I am injecting some script tags in a website, with source such as http:localhost:3000/css/my-page-css.css . While its working on almost all sites, there's this particular website that is somehow sending all my http requests as https. How do I handle such a case?
I have configured an https server also on my nodejs app which listens to port 8443 and http listens to 3000. But, when I inject my script tags, they have src URLS which point to port 3000. So even if I have an https configured on my nodejs app, it won't work since it would be listening to a different port.
You are using HTTP Strict Transport Security (HSTS)
Using the securityheader.com website on your URL, or Chrome Developer tools we see the following HTTP Header is sent back by your site:
Strict-Transport-Security max-age=7889238
This HTTP Header will be configured in your webserver and is a way of your webserver telling the browser "For the next 7889238 seconds only use HTTPS on this domain. If someone tries to use HTTP (either by typing or by clicking on a link) then automatically switch HTTP to HTTPS before you send it on to the server."
This is a security feature as currently the default (if a scheme is not explicitly given) is HTTP. This allows website owners to switch the default and, even strong that that, prevents it being able to be switched back.
HSTS is set at a domain level and it is not possible to have it on for one port (e.g. 443) but not for another (e.g. 3000) - it's either on for that domain or off.
If you really want to use HTTP then you need to remove this header and remove the remembered value of this header from your browser. While chrome allows you to do this by typing chrome://net-internals/#hsts in the URL and using the delete option, the easiest way to do this is to change the max age from 7889238 to 0, and then load the website again. And then remove the header completely.
This can be especially annoying for sites like localhost where you proxy requests and inadvertently set it for that dummy host name. You should see if your node proxy server allows you to strip off that HTTP header. Some might say it would be better if browser makers ignored HSTS for localhost, however I think it would be better if developers just stopped fighting HTTPS and used that even for development environments using a self-signed certificate that is added to your local trust store. This was you can avoid problems like mixed content, and also use features that are HTTPS only (including Brotli, HTTP/2, Geo Location...etc.) while developing (though some browsers like Chrome still allow these on http://localhost).
Alternatively set up a local DNS alias for each of your dev sites and use that with or without HTTPS as appropriate for the site in question.
I have 2 Windows 2012r2 Servers (Dev and Production) both running IIS 8. Both were configured identically as far I as know. I am in the process of installing wildcard certs on both of them.
I installed the cert on my Dev server and it's working. One thing that surprised me though was that I didn't have to add any additional bindings to any of my site configs (eg: I didn't add https/443) and just simply changing http to https in the browser is working, and showing the cert. Why is that?
My main question though is that on my Production server, before importing the wildcard cert, I tried simply changing the url for a couple of the domains I host from http to https in a browser to see what the result would be. When I do this I'm getting a redirect loop for all https tests. ???
I don't have any https URL Rewrites configured so I don't know what the cause of the redirect loop is. It does it for all sites on this server when trying to load it using https.
example:
http://mydomain.example.com (works)
https://mydomain.example.com (redirect loop)
Safari says, "...redirected you too many times. ERR_TOO_MANY_REDIRECTS"
Chrome says, "Too many redirects occurred..."
Additionally, if I load http://localhost on the server itself it works. If I load https://localhost I get an error, "Not Found - HTTP Error 404".
I should add that this Production server is behind an F5 Load Balancer so that could be playing into this behavior as well.
The cause of the redirect loop for all sites on the Production server was an irule on the F5 LB, that shouldn't have been there, that was looping port 443 back to itself. HTTPS for all sites worked after the irule was removed.
With regards to the Dev server and https sites working without having to add a binding. I also discovered that the F5 was configured to handle certs with a wildcard cert so local certs weren't even required. The data center team didn't communicate to me that the LB was configured to handle certs for these servers.
for local development I'm running a local webserver with virtual hosts to manage multiple webprojects requiring their own URL. Normally I use URLs like myproject.com.local and the real project will be located at myproject.com. Everything works fine in Safari, IE or Firefox. But Google Chrome throws a 404. As far as I know they have some kind of intelligent address bar. Is there any possibility to get it working with all domains?
Best Regards,
Bernd
I think it should be working with all domains, as long as your workstations DNS can resolve the name to an ip-address. Also, check if you have any proxy settings in Chrome, sometimes it helps to check the 'Bypass proxy for local domains'-checkbox (somewhere in the settings).
Also make sure that when you request non-standard domains or port-numbers to put http:// in front of your url.
Good luck.