You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
livebundle live command allow any user to connect to a remote developer metro server using a QR Code or Deep Link.
While this command has a lot of potential for debugging use cases for example, it also has a major restriction being that both user(s) and remote developer workstation have to be on the same network.
While it is possible for developers to open metro server port for ingress traffic on their public internet router, this is not without friction and potential security vulnerabilities.
We should think of a way to offer (or reuse one, need to do some research first) a proxy server that could be launched on a server and would proxy http/websocket traffic. LiveBundle CLI would establish a connection to this proxy upon running the live command, and would get back some kind of unique session id. The QR code / DL will be generated to contain metadata containing the proxy IP address and session ID. Mobile client would then send requests to this proxy which will be redirected to developer workstation. Obviously this proxy sever should support multiplexing (multiple live sessions in //).
As for storage providers in LiveBundle, we should add support for this in the CLI, and also potentially offer a proxy server implementation, but we will not host such a proxy for public use.
The text was updated successfully, but these errors were encountered:
livebundle live
command allow any user to connect to a remote developer metro server using a QR Code or Deep Link.While this command has a lot of potential for debugging use cases for example, it also has a major restriction being that both user(s) and remote developer workstation have to be on the same network.
While it is possible for developers to open metro server port for ingress traffic on their public internet router, this is not without friction and potential security vulnerabilities.
We should think of a way to offer (or reuse one, need to do some research first) a proxy server that could be launched on a server and would proxy http/websocket traffic. LiveBundle CLI would establish a connection to this proxy upon running the
live
command, and would get back some kind of unique session id. The QR code / DL will be generated to contain metadata containing the proxy IP address and session ID. Mobile client would then send requests to this proxy which will be redirected to developer workstation. Obviously this proxy sever should support multiplexing (multiple live sessions in //).As for storage providers in LiveBundle, we should add support for this in the CLI, and also potentially offer a proxy server implementation, but we will not host such a proxy for public use.
The text was updated successfully, but these errors were encountered: