bitshares
My ISP router DNS forwarder filters 127.0.0.1 by default
$ nslookup local.get-beet.io 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
*** Can't find local.get-beet.io: No answer
No sure what the consequence is or how serious the issue is.
I think it's a common issue. Everyone using the same type of device may encounter the same issue. Asking everyone to change their default DNS settings is not the solution IMHO.
I'm not sure about this, but have you tried adding beet.bitshares.org 127.0.0.1 in hosts file in OS ?
Sure I know how to work around locally. But it's not the key point of this issue. New users will likely simply give up if an app does not work.
Asking everyone to change their default DNS settings is not the solution IMHO.
Is 192.168.0.1 the IP of your local machine that woudl run beet in that case?
Check if it does it for all localhost addresses or just 127.0.0.1....(i.e. 127.0.0.2 or 3 or 4 etc)
Is 192.168.0.1 the IP of your local machine that woudl run beet in that case?
192.168.0.1 is my modem / router / WiFi AP with built-in DHCP server and DNS forwarder - the default settings.
Interestingly,
$ nslookup localhost 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
Name: localhost
Address: 127.0.0.1
$ nslookup localhost123 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
*** Can't find localhost123: No answer
$ nslookup local.get-beet.io 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
*** Can't find local.get-beet.io: No answer
$ nslookup loca.get-beet.io 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
** server can't find loca.get-beet.io: NXDOMAIN
$ nslookup get-beet.io 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
Name: get-beet.io
Address: 185.199.111.153
Name: get-beet.io
Address: 185.199.108.153
Name: get-beet.io
Address: 185.199.110.153
Name: get-beet.io
Address: 185.199.109.153
Is 192.168.0.1 the IP of your local machine that woudl run beet in that case?
192.168.0.1 is my modem / router / WiFi AP with built-in DHCP server and DNS forwarder - the default settings.
Interestingly,
$ nslookup localhost 192.168.0.1 Server: 192.168.0.1 Address: 192.168.0.1#53 Name: localhost Address: 127.0.0.1 $ nslookup localhost123 192.168.0.1 Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: *** Can't find localhost123: No answer $ nslookup local.get-beet.io 192.168.0.1 Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: *** Can't find local.get-beet.io: No answer $ nslookup loca.get-beet.io 192.168.0.1 Server: 192.168.0.1 Address: 192.168.0.1#53 ** server can't find loca.get-beet.io: NXDOMAIN $ nslookup get-beet.io 192.168.0.1 Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: Name: get-beet.io Address: 185.199.111.153 Name: get-beet.io Address: 185.199.108.153 Name: get-beet.io Address: 185.199.110.153 Name: get-beet.io Address: 185.199.109.153
I'm not quite sure why you still getting get-beet.io as response when we updated it for a new domain ... hmmm
Have you tried lately to use it ?
$ nslookup beet.bitshares.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
*** Can't find beet.bitshares.org: No answer
$ nslookup beet.bitshares.org 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
*** Can't find beet.bitshares.org: No answer
As I've said, the point of this issue is not what domain name you are using in the code, but what the IP address is used.
Alternatively perhaps there are tunneling solutions which can address this issue? It does introduce risk as the traffic between app and beet wallet would be proxied.
Might any of these tunneling solutions resolve your https localhost routing issues? https://github.com/anderspitman/awesome-tunneling
@grctest thanks for your suggestion. Technically I have many options to solve the issue for myself, however it's just me. As mentioned in OP,
I think it's a common issue. Everyone using the same type of device may encounter the same issue. Asking everyone to change their default DNS settings is not the solution IMHO.
In other words, what I was looking for is a solution for average end users, but not developers.
We could allow the user to select a preferred communications method (Either HTTPS+get-beet.io || HTTP).
Selecting HTTP communications preference would solve OP issue.
HTTP only is less secure, but it's over localhost not through ISP so middleman risk is low & so HTTPS justification is lessened.
We could also look into some form of URI or Deeplinking as a completely optional alternative communications method to websockets.
We use HTTPS for beet, because if the user is on a HTTPS page already, (IIRC) the browser will refuse to connect to beet using HTTP.
With the new TOTP, Raw Deeplink, QR codes and Local JSON upload features, perhaps we can now close this issue?
Users with the localhost blockage can use the above features instead of beet comms over wss.
The latest beeteos release has a dedicated page for web requests, meaning that the ISP blocked ip address and ports will not be launched/opened unless you explicitly navigate to the web request page. https://github.com/beetapp/beeteos