Direct connection to a PC should be accepted

[rgajdeczka]

There is still an important feature missing in my opinion. Direct connection to PC should be accepted. I know there is a chat, but in my opinion there should be also an acccpetation of the connection (it can be as an option for selected PCs from list in daschboard).

[futuredata123]

The idea is that you would use the instant portable agent in that case; and simply receive the session code from the other user. There is no benefit to an "accept" button on unattended installs, in my humble opinion, but I don't know all use cases.

Now, a feature I wish for but think would be grossly difficult to implement would be a low-res image of their desktop (perhaps refresh-able), or some other means to detect if a user is idle or actively performing tasks.

[bitbound]

There's also an option in the Server Config (appsettings.json) for "Enforce Attended Access." When enabled, a user must be present to allow all connections. They'll get a message like this:

[rgajdeczka]

thx, can you provide more information on how I can configure it?

[bitbound]

It's in the Server Config section for server administrators. Or you can set it manually in appsettings.json, which is explained in the readme.

[stevesobol]

Seconded.

…

On Apr 23, 2021, at 17:06, Jared Goodwin ***@***.***> wrote:  There's also an option in the Server Config (appsettings.json) for "Enforce Attended Access." When enabled, a user must be present to allow all connections. They'll get a message like his: — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bitbound]

Eventually, I'll probably make "Enforce Attended Access" settable for devices and device groups too. Same for all the other settings that should be able to be applied at all levels, like "Use WebRTC".

Then when I tackle this one, I think all use cases should be covered.

[stevesobol]

Just to be clear, I spoke up in support of the direct connection feature, although I do also think “enforce unattended access” is also a good idea.

…

On Apr 23, 2021, at 19:56, Jared Goodwin ***@***.***> wrote:  Eventually, I'll probably make "Enforce Attended Access" settable for devices and device groups too. Same for all the other settings that should be able to be applied at all levels, like "Use WebRTC". Then when I tackle this one, I think all use cases should be covered. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[bitbound]

Maybe I'm confused. I thought "direct connection" was synonymous with "unattended connection".

What am I missing here?

[stevesobol]

"Unattended", in most contexts, means Remotely or another remote-control program runs as a system service or daemon, and allows for remote control even when no one's in front of the computer.

"Direct" means that instead of going through an intermediary server, you can connect directly to another computer on the same LAN. Saves bandwidth and is generally faster.

This is how other remote-control products define those two terms, and I'm using those definitions.

[bitbound]

Ah. Remotely uses WebRTC for direct connections. You'll see it referred to as WebRTC, peer-to-peer, or P2P.

Some extra info in case anyone wasn't aware:

Right now, it only works on Windows endpoints. I tried a cross-platform library recently but had too many issues with it. So for now, I'm waiting for Microsoft to either complete or abandon their cross-platform WinRTC project.

It nearly always works when connecting to a computer on the same LAN. The only times I've seen it fail on LAN is when there's an explicit firewall rule to deny it.

Over WAN, it depends on network topology and infrastructure.

You can choose to enable/disable it server-wide or per-machine.

With all that said, I'm still not understanding why there would be an option to prompt for access specifically for WebRTC/direct/P2P connections. It goes through all the same checks of whether the logged-in user has access to the target device.

[bitbound]

Also of note, you can replace the STUN servers with a TURN server in the ICE Servers list in appsettings.json. A TURN server adds relay support when P2P can't be established.

With the default settings. if a P2P connection can't be made, Remotely will relay the traffic through the Remotely server itself. If you wanted to delegate that traffic to a different server, that's where you'd use TURN.

There's a Docker image for Coturn (the most popular open-source TURN server): https://hub.docker.com/r/coturn/coturn