Restrict usage of TURN only to authenticated users

[maximbaz]

Hello,

Thanks for the interesting project!

Thinking of a self-hosted scenario, I can see that it's possible to configure TURN server, but I would like to restrict its usage only to authenticated set of users. Say I selfhost it on webwormhole.example.com and someone finds out my server - I don't care too much if they use it with STUN (where the traffic is still going peer-to-peer), but I would like to prevent them from relaying a ton of traffic over my tiny server.

I think screego solved this issue beautifully, and I would suggest to implement something similar:

• Create a simple user-password mapping file on server side (see SCREEGO_USERS_FILE environment variable)
• In UI, there is a simple login form that can authenticate you against this file
• When you want to send a file (or start screenshare, in case of screego), if you are not authenticated, the app will only use STUN, but if you are, it will also use TURN - receivers don't have to be authenticated

If even this is too much, I imagine instead of users mapping we could have a single "relay password", so if you provide it when starting a transfer, TURN will be allowed too, otherwise only STUN. I'd prefer having multiple passwords (in case I need to give someone else a temporary one), but it's not a big deal either way.

What do you think of this idea?

[saljam]

thanks for your interest! (and for the screego links. it looks great.)

i think it's an valid idea, but i am quite strongly opposed to adding user authentication in webwormhole itself. my reasoning:

• there are too many ways to do it
• none of them are perfect
• all of them add complexity
• someone will always complain that they prefer it the other way

so i'd prefer to leave it out for something else to enforce if that's something anyone wants to enforce, e.g. a proxy server. unfortunately, that doesn't leave a trivial way to serve both from the same instance.

[maximbaz]

There seems to be no way around embedding this knowledge into webwormhole, because even if I host two instances, a public STUN-only one and a "secret" one with TURN, and say I cannot send you a file via STUN so I have to send you a file via my secret TURN instance, but then you will know about it and would be able to make use of it 😞

Why don't we pick the simplest possible approach, the less imperfect one (whichever it is) and implement only it? I don't see a problem saying "no" to requests for alternative implementation of the same thing, but to have at least one way and support a whole new range of scenarios sounds useful...? 🙂

[maximbaz]

Hello again 👋 I was just curious if you had some additional thoughts on how we could move forward with this issue?

I'm more than sold on the idea of not including "non-essential" functionality into the project itself, and I'd also much rather use some proxy, however I just can't find any way to make it work for giving temporary access to TURN to some people.

This really prevents me from using self-hosted instance, because it happens way too often that I send a file, a person cannot receive it via STUN as they are behind some weird network, and so I have to abandon my transfer, and retry with using a third-party instance with public TURN (i.e. your server), which is neither great when sensitive files are involved, nor for unnecessarily overloading your server for large files... 😕