Safety Feature: director room password

[Fred-DTV]

Currently it is quite easy for someone who knows a room name and OBS.Ninja to enter the director room as well.

This could be easily exploited, so my thought was to have a custom director room password option.

[buffos]

I second that. If you are doing some kind of a show and you need to give the url to untrusted individuals it is very likely you will end with a hijacked show.

When a room is created it should have 2 passwords. For example have password1;password2 (literally split by a semicolon). All views can be unlocked using the first part of the whole password, the directors feed would require the whole password.

This way implementation would be trivial.

• create the room as usual. The password may or may not have an semicolon.
• When any page (except from directors) is accessed, the comparison is between the first part of the password (if there is no ; the whole string is returned) and the password provided. If they match, everything is ok.
• for the directors page we compare the whole stored password (even if it has or has not an ;. it does not matter).

This way, it only requires minimal changes, namely the ones comparing the provided password with the stored one.

[steveseguin]

Thank you for feedback and suggestion.

I have been working on a system using vdo.ninja that is designed specifically for public call-in shows. I don't have an ETA on when it will be done, but it will include social-sign in, guest-blocking, permanent rooms with saved settings, and quite a bit more.

Until that is done though, I can offer a few options to help prevent abuse in rooms where untrusted guests might be invited.

• The first option is consider a transfer room. When you transfer a guest from a green room to the main room, the guest doesn't know which room they are being transferred to. You won't need to worry at least about a random person with the green room link causing problems, or having them re-join as a director once they get kicked out of the main room.

• The second option is to have the main director retain their connection, and simply not disconnect while in the room. So long as the main director remains connected, no one else can claim that spot. It's only if the main director disconnects that someone else can join the room as a new main director. The director can use &view=xx,yy to specify who they wish to connect with, so in theory, the main director could also be kept isolated, connecting only with validated scene-links.

• Using &push and &view links, without a room, allows for faux-rooms to exist, where you simply control which stream ID you wish to view/remove. There is no director, as a result. Instead, streams can be controlled via an IFRAME API for the hosts/obs for example, and each time you invite a guest in, you provide that guest a new stream ID. It's possible I could offer a proof of concept sample code for this, if desired.

• Lastly, I just created &maindirectorpassword as a URL parameter, which you add to the main director of a room's URL. It's available for testing on the alpha version of vdo.ninja. This is akin in function to what is being asked for in this git issue thread.

  ie: https://vdo.ninja/alpha/?director=ROOMNAME&maindirectorpassword=PrivatePassword

How it works: When you join a room as a director with &maindirectorpassword, with the right password, the system will auto-assign you as the current "main" director. So it doesn't matter if you were the first in the room or not, just that you use the same password that you used when you originally created the guest invite/scene links for the room.

The main downside of using &maindirectorpassword is that invite and scene links will have a &token parameter added; invites and links are a bit longer as a result. This &token is needed though because I don't let users "own" a room with a vdo.ninja, so setting a saved password doesn't work on its own. When using &maindirectorpassword/&token though, the system queries a new database server I just setup, and it checks that to see who the current room owner is of the held token, ignoring anyone else who is claiming to be the owner.

I'll do more testing on this new &maindirectorpassword feature this week, and if I can think of a way to improve it more, I'll do so.

Either way, VDO.Ninja is based on a peer to peer design, so irrespective of using director passwords or such, you'll want to practice some caution when dealing with public users. Perhaps have a backup link for hosts, if the current room starts facing abuse problems, or use transfer-rooms to help filter out untrusted guests. I hope to address all these issues though with the upcoming call-in show system; thank you for the patience until then.

[buffos]

Wow. Indeed queues and pre-screen rooms are a great way to preserve the room from hijackers. This is indeed the best way. Screen and transfer. But requires a second person to do that job (at least for some usecases).

The maindirectorpassword is a middle ground. A compromise. Not the great protection the queuing method provides, but a fast way to secure control of the room.

• If you are trying to do a "live show" and invite strangers "on air" , then queues is the only way to go.
• If you are doing a live show , with people you know, but are not 100% sure they will not try to get smart for fun, the second way is fine.

Thank you again for an amazing job.