- Verschifft
- 15. August 2026 um 05:22 UTC
- Autor
- Kamo
- Ausschuss
- 89ccc1b
MailboxController hat überhaupt kein Recht erzwungen. MANAGE_EMAIL_ACCOUNTS existierte nur als checkRecht im Browser und VIEW_EMAIL_ACCOUNTS wurde nirgendwo erwähnt, so dass jeder Postfach in einer Organisation könnte erstellt, suspendiert, gelöscht oder neu zugewiesen werden. authentifizierter Anrufer, der die URL kannte. Alles ändern dauert jetzt MANAGE_EMAIL_ACCOUNTS; Lesen administrativer Details wer einem Mailbox zugewiesen ist, was der Anbieter unterstützt VIEW_EMAIL_ACCOUNTS. getMailboxMitglieder, unassignMailbox und setPrimaryMailbox haben keine HttpServletRequest überhaupt, so hatten sie weder eine Rechteprüfung noch eine Organisationsprüfung: irgendein Anrufer könnte jede Mailbox per ID neu zuweisen. Sie nehmen die Anfrage jetzt an. Der Listenendpunkt ist absichtlich NICHT abgesperrt. GET /api/email/mailboxes ist der erste Quelle in /api/email/Verzeichnis, das den Empfänger autocomplete dahinter zurückstellt verwendenRecipientSearch, und diese Route gibt eine leere Liste anstatt eines Fehlers, wenn ein Quelle weigert sich. VIEW_EMAIL_ACCOUNTS wird von 15 von 42 Rollen gehalten und ACCESS_MAIL von 28, so gating die Liste hätte still geleert Kollegen aus dem Adressbuch von jedes Mitglied, das Mail lesen, aber nicht verwalten kann, ohne es zu erklären. Wessen Mailboxen ein Mitglied öffnen darf, wird bereits von ACCESS_ALL_*_MAILBOXES entschieden über AccessibleMailboxService. Ein Endpunkt, der sowohl dem Admin-Bildschirm als auch dem Adressbuch dient, ist der eigentliche Fehler. Splitting es würde die Admin-Ansicht nehmen Sie die richtige sollte es eine API-Änderung anstatt einer Genehmigung ein, also nicht hier gemacht. Die Klasse javadoc zeichnet dies auf so dass die nächste Person nicht "fix" das fehlende Tor und brechen Autocomplete.