- Verschifft
- 23. September 2026 um 07:49 UTC
- Autor
- Kamo
- Ausschuss
- b06e1c4
GET /export/calendar/{id' und POST /import/{calendarId' nahmen die UUID des Kalenders allein - nein HttpServletRequest, also keine Sitzung, keine Org- oder Mitgliederprüfung. Jedes authentifizierte Mitglied von jedem Organisation könnte exportieren, oder überschreiben mit einem hochgeladenen .ics, jeden Kalender in der gesamten Cluster einfach durch Erraten oder Aufzählen seiner ID. Beide lösen nun den Kalender durch MemberCalendarService - der gleiche "eigene Kalender, oder die Organisation ist mit dem Recht zu veröffentlichen, um es zu überprüfen" überprüfen GET /api/calendars, /events und POST / Veranstaltungen gelten bereits, jetzt als getReadableCalendar ausgesetzt (für den Export, eine Lektüre) und getWritableCalendar (zum Import, ein Schreiben; der Organisationskalender benötigt CREATE_ORG_CALENDAR_EVENTS). Ein Kalender außerhalb des Anrufers und deren Organisation man antwortet 404, genau so, wie es wäre, wenn der Kalender nicht existierte. Import schreibt immer noch die gepars Veranstaltungen durch CalendarService#createEvent, nicht **************** eine Masse historischer Import darf nicht die Publikums-/Einladung Nebenwirkungen einer von einem von einem Mitglied autorisierten Veranstaltung ausführen, und Bei dieser Lösung geht es darum, wer importieren darf, nicht wie ein Import angewendet wird. **************** scheitert ohne die Änderung - eine ungeschönte ID exportiert derzeit oder überschreibt einen Kalender (200) anstatt abgelehnt zu werden (401/404/403).