Room Access-Permissions Management Module Proposed algorithm

[Charlesc22]

Robin suggested I write up my thoughts on how I would like the rooms access management and whitelist to work.

Based on our use-cases and some of the use-cases I've seen discussed on Hubs Discord, I've written up a rough algorithm of how the logic could work to address most of the use-cases. I will also upload it as a file so it might be easier to read Room_Permissions2.txt And here are a couple of issue links that might be relevant

https://github.com/mozilla/hubs-cloud/issues/27 https://github.com/mozilla/hubs/issues/2486

Use-Cases 1- Ticketing and Events (Galleries, parties, events, presentations, conferences...) 2- Team Rooms (where only a group of friends or co-workers or club have access to the room) 3- Meeting Rooms (where business people meet at a scheduled time, a member can only enter the room at a scheduled time and when the moderator is in the room already. Similar to how Zoom or other online conference services work) 4- Class Rooms for Education (Only want students to be allowed in at specific times and when the teacher is already in the room)

---

definitions of different types of room users: Owner: # The hubs user that created the room Moderator_master: # Can edit the whitelist and make changes to the room, but not close the room Moderator_basic: # Can only moderate the users in the room but can not change access/whitelist or edit/close the room visitor: # User that is not logged into hubs member: # User that is logged into hubs, but not an owner or moderator of that room whitelisted_member: # User is a member that is on the white list to be allowed into the room whitelist # List of all hubs members that have permission to enter that room. Can be either Hubs UserIDs or emails calendar # Stores the time and dates that the room is accessible. The owner and Moderators have access to the room at all times

Settings bolean flags: room_permssions_settings_allow_entry_to_all_visitors room_permssions_settings_allow_entry_to_all_members room_permssions_settings_allow_entry_only_when_moderator_present room_permssions_settings_allow_entry_only_at_specific_date_and_time

Variables Whitelist calendar

def Event_on_room_load_check_room_access_permissions(): userid = Get_hubs_userid()

IF Userid_is_owner(userid):
    return(allow_entry)

ELIF Userid_is_moderator(userid):
    return(allow_entry)

ELIF room_permssions_settings_allow_entry_only_at_specific_date_and_time     # Control access by Time is turned on
     Check_if_room_NOT_available_at_this_time(current_time_and_date): #Check if there are any time and date restrictions for this room
           return(Room is not available at this time)

# If you are here, the room is available at this time, and the user is Not an owner or moderator, so next check for access permissions
ELIF hubs_userid == None   #Is a visitor or Hubs member that is not logged in
    IF room_permssions_settings_allow_entry_to_all_visitors
        IF room_permssions_settings_allow_entry_only_when_moderator_present #Check if have to wait for a moderator to be in the room before can enter
            IF Check_is_moderator_in_room()
                return(allow_entry)  #Yes there is a moderator in the room
            Else                     #No, there is no moderator in the room yet
                return(tell user to wait in the lobby till the moderator arrives, then he will be allowed to enter)
        ELSE
            return(allow_entry)

ELSE   # Has avalid hubs_userid and is a logged-in member
    IF room_permssions_settings_allow_entry_to_all_members
        IF room_permssions_settings_allow_entry_only_when_moderator_present
            IF Check_is_moderator_in_room()
                return(allow_entry)  #Yes there is a moderator in the room
            Else
                return(tell member to wait in the lobby till the moderator arrives, then he will be allowed to enter)
        ELSE
            return(allow_entry)

    ELSE  #Room is restricted by a Whitelist
        IF Member_is_on_whitelist(userid)
            IF room_permssions_settings_allow_entry_only_when_moderator_present
                IF Check_is_moderator_in_room()
                    return(allow_entry)  #Yes there is a moderator in the room
                Else
                    return(tell member to wait in the lobby till the moderator arrives, then he will be allowed to enter)
            ELSE
                return(allow_entry)
        ELSE   #Member is not on the whitelist
            return(tell member that they need to register or buy a ticket or ask the owner or Moderator_master to get added to the whitelist)

Future nice to have 1- Scheduler for Time of day room is accessible 1- Hooks to link to ticket purchasing or other 3rd party scrips 2- API to add/remove userIDs/emails to the whitelist 3- Would be great to be able to add/remove moderators to a room through the API

Miscellaneous thoughts 1- Room Permission settings and whitelist could be edited from an additional tab in the room settings by the owner of the room or the moderator_master only 2- Preferably, would have an API that would allow access to edit the room permission settings and edit the whitelist 3- For tying in a ticketing system, would need additional hooks at certain points so when someone purchases a ticket, it can call the API and add the user 4- Since the 3rd party ticketing system would not have access to the Hubs userID, perhaps the email should be used to link the ticket to the Hubs userID 5- Or could have a code (i.e ticket stub) that is what is purchased on the 3rd party ticketing system. And the whitelist could contain the list of codes 6- So the whitelist could contain 3 types of information that could give access to the room 1- Hubs User IDs 2- Emails 3- List of codes used to sell tickets in shopping carts. 7- For Events, if a user is not on a whitelist, they should be given a link to where they can buy tickets for the event 8- Having the ability to restrict entry to a room unless the moderator is in the room provides a very simple way to prevent random people from entering a room where you maybe have shared the link publicly. This allows you to re-use the same room over and over for different meetings.

[robinkwilson]

https://github.com/mozilla/hubs/issues/1821 @brianpeiris this thread may help illuminate some use cases with your current task.

[camelgod]

Great proposition! To me the most important part is to be able to create accounts from an API and add those to a whitelist externally.

The way I have designed my setup at current time is to have a Django "wrapper" around the actual Hubs infrastructure to manage payments and accounts (because I want to do other things than just Hubs, such as normal paywalled content, as well as keep user personal information managed in a way that is not a black box to me) and when a user buys a ticket or signs up for something in my Django application, it creates an account in Hubs. The hubs account then acts as a "ticket" itself.

What would be very nice is to just create a Hubs-account when a Django-account (or any third-party service really) is created, and make seperate whitelists for different events (whitelist contains users and rooms). That way I could just add/remove people from whitelists instead of creating/deleting accounts and setting up a bunch of different Hubs instances.

Having an API like proposed in future nice-to-have would be amazing. Right now my design will generate a bearer token for admin account and have Django backend do PostgREST calls, but this could perhaps be simplified by an API access token or something?

Anyway just a little description about my setup, might be the only one with such a setup and might look bizzarre but there you go :) I designed it based on what options were available 2 months ago, so I'm totally up for changing it too if we get more features like discussed here! The idea is just to let you know how it's done today, so we can use experience to make a good system. Looking forward to seeing this discussion!

[yakyouk]

Chiming in with my own notes and ideas on this: I had a similar setup as @camelgod with an external system using an admin token to create users - and identities - through the API. My setup relies heavily on identities and I have some checks to ensure identities exist for each user and are unique: identity unicity is NOT enforced in Hubs. For setting people as room admins (manually) I ran something like that directly on the DB (don't think there's a postgrest endpoint for it): insert into hub_role_memberships (hub_id, account_id, inserted_at, updated_at) select hubs.hub_id, identities.account_id, NOW(), NOW() from hubs, identities where identities.name in ('identity1','identity2') and hubs.hub_sid in ('ABC1234','DEF5678');

Some random suggestions for room access:

• use tags on rooms for access - similar to avatar listings - and enable or disable tag checking with a checkbox
• add a single role field to users that will be checked against tags - could be used for avatar listings too!
• for room owner or promoted user, allow un/setting any user (from a full list of users, not by clicking on in-room users) as a "room admin" or "restricted room admin" - or any amount of granular rights.
  • possibly restrict this to system admins only so we don't expose a full list of users to non-admins
  • non-system admins could still be able to give rights to users that are currently in the room

Restricting access on a schedule - except for owner(s) - might come handy but may be very specific. Is it a good idea to have that per room? or rather to have a manual global setting to enable or disable sign in / sign up? Concern with restricting access when moderator is present (could be generalized to: when (a) given person(s) within a list is present): what happens when given person experiences connection issues, do other users get kicked?