-
Notifications
You must be signed in to change notification settings - Fork 29
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
API end-point for discovering public tunnel address #144
Comments
Shouldn't the tunnel address be something easy to reproduce, for example, from the user email + box label (https://ferjm-gmail-com-home.foxlink.org)? Think about the case where the user wants to install and use a new app. If we depend on the nupnp step to get the tunnel address, that means that the user needs to be in the same network as the box to start using this new app. Is that a limitation that we want to have? |
Like the idea of auto discoverable, but using the email we will be leaking user information, when later on we will open the box to 3rd parties. |
Email was just an example. We could use unique labels for boxes. |
Yes, only being able to request client pairing from the local network, or using a PIN from an already paired client, is a feature. Without that, you would get lots of spam requests. I also thought maybe the tunnel address could already be advertised over nupnp, but this unnecessarily leaks extra information and also doesn't port well to QR codes. So I think the easiest way would be the client doing a |
We are adding the tunnel url to the registration server at fxbox/registration_server#11 so I guess this one is not needed anymore. Please, reopen it if I am wrong. |
At first, the App connects to the Box on its local IP (as discovered through nupnp). Once the App has successfully authenticated, it should have some way to ask the Box for its tunnel address (if any).
The text was updated successfully, but these errors were encountered: