Permission model¶

User types¶

There are multiple user types:

Person - A user account representing a regular attendee (or moderator, or admin) with access to the regular Venueless interface.
Anonymous user - A “light-weight” user account representing an attendee of an in-person event with temporary access to specific features in specific rooms of the event.
Kiosk – A user account only used internally to enable authentication for a kiosk-type display in an event venue.

The user type is relevant for some of the permission logic (see below), but also for other purposes (will determine if a user’s actions are relevant for statistical purposes, if the user shows up in lists, …).

Permissions¶

Permissions are static, hard-coded identifiers that identify specific actions. Currently, the following permissions are defined:

world:view
world:update
world:announce
world:secrets
world:api
world:graphs
world:rooms.create.stage
world:rooms.create.chat
world:rooms.create.bbb
world:users.list
world:users.manage
world:chat.direct
room:announce
room:view
room:update
room:delete
room:chat.read
room:chat.join
room:chat.send
room:invite
room:chat.moderate
room:bbb.join
room:bbb.moderate
room:bbb.recordings

These strings are also exposed through the API to tell the client with operations are permitted.

Roles¶

Roles represent a set of permissions and are defined individually for every world. As an example, these are just some of the roles that are defined by default in a new world:

"roles": {
  "attendee": [
    "world:view"
  ],
  "viewer": [
    "world:view",
    "room:view",
    "room:chat.read"
  ],
  "participant": [
    "world:view",
    "room:view",
    "room:chat.read",
    "room:bbb.join",
    "room:chat.send",
    "room:chat.join"
  ],
  "room_creator": [
    "world:rooms.create"
  ],
}

Roles are not exposed to the frontend currently.

Explicit grants¶

A role can be granted to a user explicitly, either on the world as a whole or on a specific room. Currently, this feature is mostly used to implement private rooms and invitations, but it could be the basis of more dynamic permission assignments in the future. Example grants look like this:

User 1234 is granted
  - role room_creator on private room 1, because they created it
  - role participant on private room 1, because they've been invited
User 4345 is granted
  - role speaker on workshop room 1, because they've been granted the role by an admin
User 7890 is granted
  - role moderator on the world, because they've been granted the role by an admin

Implicit grants and traits¶

Traits are arbitrary tokens that are contained in a user’s authentication information. For example, if a user authenticates to venueless through a ticketing system, they might have a trait for every product category they paid for.

Both the world as well as any room can define implicit grants based on those traits. For example if anyone with both the pretix-product-1234 and the pretix-product-5678 should get the role participant in a room, the configuration would look like this:

"trait_grants": {
  "participant": ["pretix-product-1234", "pretix-product-5678"]
}

In the configuration frontend, this would be shown as:

pretix-product-1234, pretix-product-5678

It’s also possible to have “OR”-type grants:

"trait_grants": {
  "participant": ["pretix-event-foo", ["pretix-product-1234", "pretix-product-5678"]]
}

In the configuration frontend, this would be shown as:

pretix-event-foo, pretix-product-1234|pretix-product-5678

The “empty” grant applies to all users, regardless of their traits:

"trait_grants": {
  "participant": []
}

However, one exception is made here: The “empty” grant will not be respected for users with a user type other than “person”.