- Enviado
- 23 de setembro de 2026 às 07:49 UTC
- Autor
- Kamo
- Confirmação
- b06e1c4
GET /export/calendar/{id} e POST /import/{calendarId} tomaram o UUID do calendário sozinho — não HttpServletRequest, então nenhuma sessão, nenhuma org ou verificação de membro em tudo. Qualquer membro autenticado de qualquer organização poderia exportar, ou substituir com um upload .ics, qualquer calendário em todo o cluster simplesmente adivinhando ou enumerando seu id. Ambos agora resolvem o calendário através do Serviço do MembroCalendar — o mesmo "calendário próprio, ou o organização tem o direito de publicar para ele" verificar GET /api/calendar/calendars, /eventos e POST /eventos já se aplicam, agora expostos como getLeatableCalendar (para exportação, uma leitura) e getWritableCalendar (para importação, uma escrita; o calendário da organização precisa CRIAR ORG CALENDÁRIO EVENTS). Um calendário fora do próprio interlocutor e sua organização compartilhada um responde 404, exatamente como seria se o calendário não existisse. Importar ainda escreve o analisado eventos através do CalendarService#createEvent, não **************** a granel a importação histórica não deve executar o público/convidar efeitos secundários de um evento de autoria de um membro, e esta correção é sobre quem pode importar, não como uma importação é aplicada. **************** falha sem a mudança — um id não vigiado atualmente exporta ou substitui um calendário (200) em vez de ser recusado (401/404/403).