My application runs on localhost (both front-end and back-end, but on different ports). FE runs on http, but BE is on https.
All modern browsers allow adding exception so that https://localhost is accessible.
Except IE and Edge.
I've tried every option I have came across but none worked. I've added both http and https versions of localhost to Trusted Servers under "internet options". Did not work. I've checked host file, cleared cache, checked security options ...
What baffles me is that the request should be POST, but somehow the IE network panel shows it as GET. Other browsers send OPTIONS followed by POST, but IE fires GET and blocks it. It never hits the server.
What should I do to fix this?
And yes, unfortunately I DO HAVE TO support old IE, damn!
Whoa, solved by accident.
There is also Swagger running on my BE localhost. When I've tried to access it in IE, it showed warning about the invalid certificate. And only then was I able to install that certificate to IE, so that even IE would accept it.
So now when IE finally has the certificate, the request passed.
No usefull error message has been shown at all, so it took me considerable time to solve it. Damned IE.
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.
my Node.js server is supposed to send a GET request to a third-party website vie https.get, but that website returns a 503 error, which is strange, because when I send the exact same request from my own device everything works as intended. Does anybody know what may be the cause of this problem, and how it can be fixed?
EDIT: The website uses CloudFlare, it might be related to theproblem but still - it works in my device.
Checking if the site connection is
shahed4u.vip needs to review the security of
If you are using cloudflare it's just normal, because cloudflare prevent access to bots.
Note: all informatical program making HTTP request are bots, is considered as "true clients" by cloudflare browsers with graphical instance, cookies, and algorythm (check this article on how cloudflare detect "bots")
Using Chrome, when I'm trying to change values of an input located in an IFrame of another app on our server, I get an error in Chrome:
"Blocked autofocusing on a form control in a cross-origin subframe."
On production (when the two apps are hosted on the same domain) it's working, but on localhost development I can't make it to work.
I've already tried starting Chrome with the following:
--disable-web-security
--ignore-certificate-errors
--disable-site-isolation-trials
--allow-external-pages
--disable-site-isolation-for-policy
but none worked.
Has anyone has an idea how to make it work?
If any change on server side needed, it's also an option.
For me the issue was a chrome extension ( Dashlane ). I disabled it on that site an it worked. I don't know if this helps you in any way but I had the same issue and this worked for me.
edit: I also had the issue on localhost however haven't tried it yet on server.
Go to chrome://flags
Disable SameSite by default cookies
Relaunch chrome
I've got a requirement to detect if a webpage is being served on the internet or intranet, i.e. assuming a url of https://accessibleanyway.com, is the phone connected to the work wifi or to something else like their home wifi or the phone network?
What different ways are there to do this?
(1) Use WebRTC to get the local ip address. Not widely supported
(2) Try to access a local web page using jsonp/cors/iframe
The problem with 2 is that the webpage is https and the local resource is likely to be http which you can't do in IE afaik. If I make the local resource https then it's via a self cert which means installing CAs on the phones (can you buy certificates for the intranet anymore?)
Any suggestions?
The problem with (2) was that the same page was trying to use http and https, and even with an iframe you get issues.
What you could do instead is start on a http loading page, use an iframe to access a local resource which you can only access if you are on the intranet, jsonp will work fine for this. Once that's worked or failed, redirect to your start page with some token in the querystring to indicate that you are on the intranet or not
NB jumping from http to https would probably have some security issues if you are on the same website (authentication cookies being initially visible), but I would have thought it would be fine if you are going to a different one
Obviously there'll be some security needed around the token as otherwise the user could just generate their own but that's a different matter which depends on individual setups. It would obviously have to be generated by a server call, otherwise someone could just read the client code.
NB I think the IP address approach is never going to work as you have no way of knowing what a companies intranet setup looks like until you go there, so it's not a generic answer
I have been looking for a way to make sure my web server is secure against a man in the middle attack. It does seem that Google Chrome and Firefox work in blocking requests to my server even if I select to advance after the security warning. I am testing this by using Charles Proxy to intercept Https traffic without having trusted the Charles Cert on my Mac.
When I run the same tests with Safari it will let me through if I chose to ignore the secure warning, which I expect a certain number of users to do. So it seems there is more configuration needed to lock down Safari traffic. I know this is possible because when trying to navigate to github.com with the same scenario I get the following message:
Does anyone know what GitHub is doing to block Safari traffic on an untrusted connection?
Looks like Safari is supporting HSTS and that github is using it. Their HTTP response contains the following header:
Strict-Transport-Security:max-age=31536000; includeSubdomains; preload
This way a browser supporting HSTS knows that for the foreseeable time this site should only be visited with https and any attempts to use http only will automatically be upgraded by the browser.
Apart from basic HSTS which only works after the first visit of the site github also adds the preload directive. This tells browser makers that github likes to be included in the preloaded HSTS list shipped with the browsers, so that the browser applies HSTS even if the site was never visited before by the user. See HSTS Preloading for more information.