Anonymous users are able to create a new room

[s-and-witch]

Bug Report

I saw this issue: #28, it's marked as "completed" but I don't see any effect.

Problematic behavior
You can go into any meet.example.com/abc-abab-abc url and create a conference without ever being logged in. That opens a wide range of possible abuses for self-hosted instances.

Expected behavior/code
Anonymous users should be able to join rooms that were created by registered user and they should not be able to join empty rooms.

Steps to Reproduce

1. Go into meet.example/abc-abab-abc
2. You may be redirected to a OIDC callback sometimes. Ignore that, open the conference link one more time.
3. And then the bug happens!

Environment

• Meet version: 1.15.0
• Platform: latest NixOS unstable
• I think I should mention that I have ALLOW_UNREGISTERED_ROOMS = "False", it doesn't seem to take effect there.

Possible Solution

I did run LLM on the codebase to investigate this problem, but it generated solution that's kinda bullshit. I will include it anyway, but hide behind details.

Relevant parts of AI output

It says that the problem is here:

The vulnerability is in the frontend, in src/frontend/src/features/rooms/components/Conference.tsx:83-86:

queryFn: () =>
  fetchRoom({ roomId, username: userConfig.username })
    .catch((error) => {
      if (error.statusCode == '404') {
        createRoom({ slug: roomId, username: userConfig.username })  // <-- THIS
      }
    }),

When any user (including anonymous) navigates to a non-existent room URL like /some-slug:
1. fetchRoom() returns 404 (room not in DB)
2. .catch() fires and calls createRoom() — making a POST /api/v1.0/rooms/
3. Even though the backend RoomPermissions (permissions.py:55) blocks this POST for anonymous users, the frontend still sends it

And suggests this solution:

// In Conference props, add: isLoggedIn?: boolean
// In the .catch() handler, wrap createRoom with auth check:
if (error.statusCode == '404') {
  if (isLoggedIn) {
    createRoom({ slug: roomId, username: userConfig.username })
  }
}

That looks wrong. Why the fix should live in the frontend? Clearly, it is a backend task to ensure permissions. But LLM has more knowledge of the codebase than I have, so maybe there is a point.