The Local Testing connection could not be configured - browserstack

I can’t run local testing(for example http://localhost:3000) on browserstack.
I'm using Linux Mint 18.3 Sylvia x64. Browser is Chromium.
The browser’s extension (app) is installed.
The screenshot shows that there is no connection.
http://joxi.ru/Y2LJBv0H9MBv8r
The checkbox is checked.
http://joxi.ru/1A5PvVpCnzMww2
I tried this manual https://www.browserstack.com/local-testing.
./BrowserStackLocal --key
The above command is started, but nothing happened.
BrowserStack's Support Answer:
Thank you for joining the screen share session. As per our investigation, it seems that few of the IP's of our servers hosted on AWS are blocked due to Telegram blockage by Roskomnadzor which is leading towards the issue.
Having said that, our team is evaluating alternate solutions for our Russian users and I will be sure to notify you of the developments.
Cool!
But my neighbour doesn't have problems, he has Windows.
We have a common Internet provider.

Try replacing 'localhost' in the URL you are using with the IP address of the machine. For example, if you are testing the URL "http://localhost:3000/index.html" try using http://<machine_ip_address>:3000/index.html instead.

Related

SSL_ERROR_NO_CYPHER_OVERLAP - but only on a few select Systems

I encounter the problem when I try to access the website of my software engineering uni course. On my desktop (Win10), phone and tablet (both Android) I receive a "SSL_ERROR_NO_CYPHER_OVERLAP"-Error when trying to access the site.
The error appears regardless of browser, it seems to be system-wide.
Interestingly enough I can access the site on my laptop (Win10 + Manjaro) and could also access it on my desktops Manjaro partition. I could also access it on my phone in the uni-network - but not using mobile data.
However I am not sure, whether mobile data is to blame, as I logged in with my firefox account before receiving the error. Naturally I assumed it may have something to do with my firefox-preferences, but i am using the same account on my Manjaro Systems as well as the Win10 partition of my laptop. Besides me, none of my friends, except one have this problem.
I ran the URL through multiple different SSL-Checkers and every one of them encountered problems regarding the SSL-certificates. As the problem occures in different networks I can also rule out some router-settings of my home-network being the cause. Have you encountered such an error before and is there anything I can do on my own or is this an issue I should take up with my course-instructor and ask him to take a look at his server?
As it turns out the browser plugin "HTTPS Everywhere" was causing the problem.
The error occured in different browsers without the plugin because I copy-pasted the https URL. The issue appeared on my phone because of the shared browser history, which autocompleted the URL to the https version. The plugin is not installed on my Manjaro's Firefox, which is a bit strange as I though it would be shared.
Additionally, on Manjaro, Firefox does not suggest the https version of the site for auto-completion - maybe it favors sites opened on the specific device over sites opened on different devices. Either way, it works now.

Opening a Neptune Notebook on a different browser (not the default one)

OK, so I've gotten acquainted with Neptune notebooks (a fork of Pluto notebooks) and they work fine on my machine, even on the FF browser (my default browser right now).
However, as the printing capabilities of these notebooks aren't quite there yet, I need to open a notebook on Chrome (or its open-source version, Chromium). When I try to do that, I get an authentication error (something about a "secret" that it needs, though it's quite vague as to what that is and where it would be inputted on the browser). I have full access privileges to all the folders involved, on my Linux Mint machine, running one of the latest versions of Julia.
Is there a way to do that, without having to make that my default browser?
Thanks
Just use the option launch_browser=false when starting Neptune.
julia> Neptune.run(;launch_browser=false)
Go to http://localhost:1234/?secret=xs5m1mnx in your browser to start writing ~ have fun!
Press Ctrl+C in this terminal to stop Neptune
Now copy the link that you see in console (http://localhost:1234/?secret=xs5m1mnx in my case) to Chromium and have fun!

ERR_CONNECTION_REFUSED exclusively in browsers

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/

Mod_Spdy not running on Centos

I'm setting up Apache on Centos the way I have done in the past, but for some reason mod_spdy is not running. I'm following the instructions here:
https://developers.google.com/speed/spdy/mod_spdy/
When I run rpm -U mod-spdy-beta_current_x86_64.rpm I get this message:
warning: mod-spdy-beta_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
package mod-spdy-beta-0.9.4.3-420.x86_64 is already installed
If I open chrome://net-internals/#spdy and my site in another tab, it doesn't show my site. If I look in the network panel, I don't see the x-mod-spdy header.
Update: If I use Firefox firebug, I see the x-mod-spdy header. I don't see my site in Chrome spdy sessions, but I see other sites in it.
What could I be doing wrong?
Ok it seems the issue is that Chrome 40.x dropped support for SPDY/3 and only supports SPDY/3.1, but the mod_spdy module for Apache only supports SPDY/3, so basically no SPDY for Chrome users if you use Apache as a web server.
mod_spdy is currently in a bad state where either Google nor Apache is maintaining it after Google donated it to the Asf. Google recently made the statement that they will drop the SPDY support from Chrome in early 2016, but what they forgot to say that they started dropping older versions of SPDY already (including SPDY/3) (I like these partially true statements by the way), so basically if you are on Apache then for your Chrome users you can't provide SPDY short of implementing SPDY/3.1 yourself.
So, how was that "do no evil"? :-)
See details: https://groups.google.com/forum/#!topic/mod-spdy-discuss/FPEj0zG5I0Y
and https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20Stars
One option you might consider is switching to Nginx and using SPDY/3.1 over there.

how to test open graph on localhost

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/