Well this is odd. As of this morning, Chrome is responding with ERR_CONNECTION_REFUSED when it attempts to connect to web pages at various {subdomain}.localhost domains. Firefox and Safari both connect as normal. I am using Vagrant/Virtualbox running Debian and Apache. Chrome does connect to local domains which ARE NOT using localhost in the domain name. Wondering if chrome released some sort of local firewall?? But not seeing anything about that in release notes.
UPDATE: running curl {subdomain}.localhost in terminal gives me the output as expected (response from web server).
UPDATE 2: I did just find this: https://news.ycombinator.com/item?id=9210484 (Chrome team planning to block all access from browser to localhost wss) -- but I do not see that this was implemented yet.
The answer is in my second update. No more .localhost.
you can try using the port explicitly -> xxx.localhost:8080
Related
Im running chrome headless through chromedriver and selenium via python.
I've run into the following issue both on Mac and Linux.
Im starting chrome as follows:
if self.headless:
options.headless = True
options.add_argument("--headless")
if self.debug_port:
logging.info(f"Setting up remote debugging on port {self.debug_port}")
options.add_argument(f"--remote-debugging-port={self.debug_port}")
options.add_argument(f"--remote-debugging-address=0.0.0.0")
If I connect to http://localhost:9222 from another headed instance of chrome I can see the list of sessions and connect to it seamlessly. At which point i have a window opened up with a screencast of the remote session and the dev console.
Here's that successful example:
When I connect to http://192.168.1.194:9222 I get the list of sessions just fine and upon selecting one the dev console opens but it doesn't start the websocket connection to ws://192.168.1.194 so the screencast and remote debugging capabilities are not available.
Here's that failed example:
I've captured har files and uploaded them here if you want to take a look
Using the following steps I was able to debug remotely. However the screencast functionality did not work. Ultimately that's what I needed so this is only a 50% solution in my case.
So, as noted above in the comments, what's blocking remote debugging from working is that the chrome debugger links out to https://chrome-devtools-frontend.appspot.com/..... and passes a value of ws://192.168.1.194 for the websocket parameter. Any browser will inherently block this, based on it being mixed content - i.e: https + ws
What's needed here is to run the chrome dev tools frontend on a http server
and direct your chrome instance to that server instead of the appspot instance.
Solution Steps
1 Install depot_tools (pre-requisite for building)
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
2 Checkout the devtools-frontend repo
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#checking-out-source
3 Build chrome devtools frontend
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#build
4 Start the devtools-frontend http server
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#running-in-hosted-mode
5 Run 2 instances of chrome and use one to debug the other
5.1 Start first instance of chrome headless
...with remote debugging enabled. See the python way in the question above or do it from the command line with the same arguments
5.2 Start a second instance of chrome
...using a different user data dir --user-data-dir=<some-path>
5.3 Navigate to http://192.168.1.194:9222
Use whatever the IP address of the first chrome instance is and the port that you chose.
5.4 Create a link to the local dev server
The 2nd instance of chrome will now be showing you links to debug each of the open tabs of the 1st instance. However the links will still to go https://chrome-devtools-frontend.appspot.com/..... You'll need to copy n paste the link you want and replace the hostname with the hostname of the devtools frontend that you started in step 4
Walla!!
If you figure out how to get the screencast working please comment below! 🙏
N.B:
I also tried using the npm run server command in the devtools frontend but for some reason that server didn't work at all ¯\_(ツ)_/¯
I'm making a web app that uses WebRTC but it requires https. Is there any way to turn off SSL check on Chrome and Firefox for localhost only or is there any way to make use of WebRTC without https? Thanks.
Chrome has chrome://flags/#allow-insecure-localhost which will ignore certificate errors on localhost. This makes development much easier.
As #vcsjones said
Both Chrome and Firefox treat localhost as a secure context, so localhost should have access to secure context only features like webcam, geolocation, and WebRTC.
It is correct. However, Firefox changed (since Firefox 42) mozSrcObject to srcObject. I changed it to that and it worked.
Since chrome://flags/#allow-insecure-localhost feature is removed from Chrome 88 disable security settings completely helped me to send requests from localhost to server.
Google Security Settings
The way to continue and access the server will be by clicking on an empty location at the background with the browser's error page and type:
thisisunsafe
I was working on a website on my local computer (mac OS High Sierra) and had put some redirects in the websites .htaccess file (in order to get images from the remote server instead of downloading them). After this it seemed that I could no longer access the website from my Chrome browser. Chrome would answer to any URL leading to the remote server with ERR_CONNECTION_REFUSED.
I tried other browsers on my computer such as Firefox, Chrome Canary, Chromium and Opera. None of them could provide a connection.
Next I checked with a different internet access via TOR-Browser on the same computer whether I could access the website, and it worked.
Next I checked via Terminal whether I could connect to the remote server with ping, nslookup and traceroute. All connecting to the server as expected.
I googled up possible solutions to this problem but could not find one so far. I had read that resetting the DNS cache could help and tried sudo killall -HUP mDNSResponder but it did not.
I did not edit the /etc/hosts file; a restart of the computer did not help; a reset of the .htaccess to the previous state did not help; resetting the caches in the browsers did not help.
How can I access the remote website from my browsers normally again?
EDIT1: Related question: Failed to load resource: net::ERR_CONNECTION_REFUSED for only selective images from instagram API
EDIT2: After about one day I was able to access the remote website again with no further incidents of ERR_CONNECTION_REFUSED even after putting the redirects into the .htaccess file. So it seems to me of being some sort of caching on my computer which prevents the browsers from accessing the remote website. However I have no clue what caused the error message in the first place and what kind of cache it might be.
Shortly after EDIT2 when I was able to access the remote website again, the ERR_CONNECTION_REFUSED appeared again - this time I tested another device with the same internet connection and I had encountered the connection error too. Now I believe it has something to do with the router and/or it's firewall - not the ISP since I could connect to the remote website with shell commands (named above). The image requests to the remote website seem to cause the router to block further access from browsers, probably as a security measure similar to the situation in this article https://www.cnet.com/forums/discussions/can-t-access-a-specific-website-going-thru-my-router-274637/
I've done a lot of research and haven't found a definitive answer to this. Is there anyway to test the open graph on localhost? I don't haven any issues using the graph api on locahost.
I've changed my website url in the app settings and have even tried setting up a domain in my hosts file but the debugger linter for open graph tries to use the actual domain instead of my localhost and when using locahost directly the linter completely fails connecting.
Does anybody have any workarounds for this?
Using a local proxy is the right solution. ngrok didn't work for me neither.
A similar tool that did work with facebook debugger is localtunnel ✅
npm install -g localtunnel
lt --port 8000
# or using npx without installing localtunnel
npx lt --port 8000
Generates a url that looks something like https://<random_hash>.localtunnel.me/. Using this url in facebook open graph debugger worked for me as of October 18th 2017. I only had to hit Fetch new scrape information button. 🍻
Cool thing about localtunnel is that you can easily host your own localtunnel server with github.com/localtunnel/server so if it ever stops working with localtunnel.me, you can run your own somewhere in the cloud ⛅
You can use ngrok to create a random public subdomain that routes to your local webserver very easily, even through NAT or firewalls.
Just download ngrok and run ./ngrok http 8080 (assuming 8080 is your local webserver http port).
This will create a random subdomain like http://38a84a97.ngrok.io/ that routes to your local webserver and that you can use with Facebook to test your open graph tags.
Its very simple to test Open Graph in any local environment using Chrome or Firefox using plugins. I have used one to quickly show in chrome how the Open Graph looks to the viewer to test results. Here is a quote of what it does.
This extension shows how people will see your site in the most popular
social networks This extension is for professionals who creates a
media content.
To check meta-information of your site or article just open it in a
Chrome and click extension's icon. Also you could add an URL manually.
Here is a direct link to the plugin (Chrome)
Firefox add-on
As a bit simpler approach you can use a browser extension like https://socialsharepreview.com/browser-extensions - which will show your Social Cards directly in the Browser (which of course might fail, if you wrongly didn't set them serverside :))
To test open graph (and Twitter cards) I also had to expose localhost (Docker) to Facebook and Twitter. I used Serveo
It works very well for this, no need to install anything as it works with ssh port forwarding.
$ ssh -R 80:localhost:3000 serveo.net
Then navigate to the url given, and there you go.
You have to setup a public domain which points to your public ip address.
Use dynes.org or a similar service and setup your router to forward your port 80.
There are several tools you can use for serving something up over your localhost, each with varying degrees of functionality.
I prefer (obviously) http://forwardhq.com
Other great options here: http://devblog.avdi.org/2012/04/27/http-forwarding-services-for-local-facebook-development/
If anyone is looking to preview the :og tags on while developing on subdomains (using lvh.me) in localhost. You can use https://serveo.net.
Simply use following command to forward your local server requests. No installation required.
ssh -R yoursubdomain.serveo.net:80:yoursubdomain.lvh.me:3000 serveo.net
you can put your desired port in place of 3000.
Reference: https://blog.aarvy.me/2019/09/20/expose-local-apps-having-subdomains-to-web/
I'm running WAMP on Vista and have Apache virtual hosts and my hosts file all set up to allow me to test sites locally using an address like this:
http://testsitex.localhost:8080
Only problem is, it only works in Firefox. IE and Safari (currently the only other browsers I've tried, and the two I'm most concerned about) display an an error.
I'm not currently in front of my machine but the error is something along the lines of:
502 Bad Gateway
Problem with DNS Host Lookup
Can anybody tell me what's going on?
I would try changing it from testsitex.localhost to testsite.loc and see if you have the same problem. Alternatively, try pinging it from the command prompt, and see if you're seeing the same problem.
Another thing might be that Firefox ignores the windows proxy, whereas IE and Safari likely use the default windows proxy (settings -> control panel -> internet -> connections -> lan settings). If your proxy doesn't have the hosts file, this would explain it.
Have you put testsitex.localhost into your HOSTS files?