-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
My ISP router DNS forwarder filters 127.0.0.1 by default #166
Comments
I'm not sure about this, but have you tried adding |
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.
|
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) |
192.168.0.1 is my modem / router / WiFi AP with built-in DHCP server and DNS forwarder - the default settings. Interestingly,
|
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 ? |
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,
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 |
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.
The text was updated successfully, but these errors were encountered: