- Ya
- 15 Agosti 2026, 01:20 UTC
- Mwandishi
- Kamo
- Ahadi ya
- e6cf9d3
/api/meet/create checked only that you had a session, so every authenticated member of every organization could create a meeting with the org's provider — START_MEETING has been grantable and decorative for as long as it has existed. /api/meet/join-info was the same, and it hands back the meeting's passcode and provider join URL, so any member holding a meeting id could read the credentials for any meeting in the org. Both now go through MeetSessionResolver, beside the canManageMeetSettings check the settings endpoints already use. START_MEETING deliberately does not re-check VIEW_MEETINGS, its parent: hierarchy closure revokes a child whose ancestor chain is not granted, so a session carrying the child carries the parent by construction, and hand-rolling the pair here is the requireAll duplication the hierarchy exists to remove. The checks fail closed on a session with no rights array. That is the same reasoning that kept the client's "type unknown -> allow" fallbacks out of the server-side share checks: a legacy-session exemption becomes a permanent bypass. This locks out anyone who does not hold the right — 36 of 69 members on production today — so it must not ship without MeetRightsSeedMigration in KamoInitializerService, which grants both rights to every existing role.