- Expédié
- 10 août 2026 à 18:04 UTC
- Auteur
- Kamo
- Commite
- 987756a
GET /api/calendar/calendars a pris userId comme paramètre de requête, changeant donc un nombre dans l'URL lire les calendriers de n'importe qui et parce que les calendriers transportés pas d'organisation du tout, dans tous les locataires. Pire, aucune mutation n'a été contrôlée n'importe quoi: POST a lié un utilisateur entier de sorte que l'appelant a choisi son propriétaire, et PUT et DELETE sur les calendriers et les événements résolus par id sans test de propriété quel qu'il soit. N'importe quel membre peut éditer ou supprimer n'importe qui. L'organisation et le membre viennent maintenant de la session établie. MemberCalendarService maintient la trajectoire à portée de membres. CalendarService Séjours la façade au niveau de l'entité CalDAV et la part de synchronisation externe, parce que ceux-ci authentifier un compte plutôt qu'une adhésion - un véritable niveau différent le champ d'application, pas un oubli. Le calendrier d'organisation est lisible par chaque membre et seul. avec CREATE-ORG-CALENDAR-EVENTS. Un refus est de 403, et non de 404: le membre peut voir le calendrier, donc prétendre qu'il n'existe pas serait un mensonge le client ne peut pas agir. Un client ne peut pas non plus promouvoir son propre calendrier en envoyant isOrgCalendar - ce drapeau est ignoré sur la création. Les charges utiles deviennent des DTO. Le membre, l'organisation et l'utilisateur des entités les associations sont paresseuses, donc Jackson les a rendues comme nulles et un client pourrait ne pas dire de quel calendrier il était tenu. L'événement DTO est privé et est récurrente même si rien ici ne varie sur eux: le modal lie les deux à commutateurs, et une valeur manquante tourne une entrée contrôlée incontrôlée. listEvents accepte également startDate/endDate. Le navigateur a toujours envoyé ceux-ci contre une signature qui ne commence/fine que de côté, de sorte que chaque demande est arrivée avec Pas de fenêtre du tout.