- Expédié
- 23 septembre 2026 à 07:49 UTC
- Auteur
- Kamo
- Commite
- b06e1c4
GET/export/calendar/-id et POST/import/-calendarId- a pris l'UUID du calendrier seul - non HttpServletDequest, donc pas de séance, pas d'orgg ou de vérification du tout. Tout membre authentifié d'un une organisation pourrait exporter, ou écraser avec un .ics téléchargé, n'importe quel calendrier dans l'ensemble du groupe simplement en devinant ou en énumérant son id. Les deux résolvent maintenant le calendrier par l'intermédiaire de MemberCalendarService, le même "propre calendrier, ou le l'organisation ayant le droit de publier à son dessus" vérifier GET/api/calendars/calendaires, /events et POST/événements s'appliquent déjà, maintenant exposés comme getReadableCalenddar (pour l'exportation, une lecture) et getWritableCalendar (pour l'importation, une écriture; le calendrier de l'organisation a besoin CREATE-ORG-CALENDAR-EVENTS). Un calendrier en dehors du propre de l'appelant et de l'organisation partagée on répond 404, exactement comme il le ferait si le calendrier n'existait pas. L'importation écrit toujours le parsed événements par l'intermédiaire de CalendarService-createEvent, pas un encombrement l'importation historique ne doit pas faire fonctionner l'audience/les effets indésirables d'un événement d'origine d'un membre qui est rédigé, et Il s'agit de savoir qui peut importer, et non comment une importation est appliquée. - échouer sans le changement - une id non portée à l'exportation actuelle ou écrase un calendrier (200) au lieu d'être refusé (401/404/403).