- Shipped
- September 23, 2026 at 7:49 AM UTC
- Author
- Kamo
- Commit
- b06e1c4
GET /export/calendar/{id} and POST /import/{calendarId} took the calendar's UUID alone — no HttpServletRequest, so no session, no org or member check at all. Any authenticated member of any organization could export, or overwrite with an uploaded .ics, any calendar in the whole cluster simply by guessing or enumerating its id. Both now resolve the calendar through MemberCalendarService — the same "own calendar, or the organization's with the right to publish to it" check GET /api/calendar/calendars, /events and POST /events already apply, now exposed as getReadableCalendar (for export, a read) and getWritableCalendar (for import, a write; the organization calendar needs CREATE_ORG_CALENDAR_EVENTS). A calendar outside the caller's own and their organization's shared one answers 404, exactly as it would if the calendar did not exist. Import still writes the parsed events through CalendarService#createEvent, not **************** a bulk historical import must not run the audience/invite side effects a member-authored event does, and this fix is about who may import, not how an import is applied. **************** fails without the change — an unscoped id currently exports or overwrites a calendar (200) instead of being refused (401/404/403).