- Verschifft
- 22. August 2026 um 23:17 UTC
- Autor
- Kamo
- Ausschuss
- b31fb30
imgs_assoc_id_check erlaubte assoc_id 0..13. ImageAssocType.PICTURE_FRAME ist ordinal 14, also hat JEDEN Bilderrahmen-Upload dagegen verstoßen. Hibernate schreibt CHECK (col BETWEEN 0 UND N) für einen @Enumerated(ORDINAL) Spalte, wenn es CREATES die Tabelle und aktualisiert sie nie wieder, so N ist die enum's Größe am Tag der Tabelle gemacht wurde. Anhängen Sie einen Wert und jeden Einsatz Das Tragen des neuen Ordinals verstößt gegen eine Einschränkung, an die niemand erinnert. Der Ausfall ist ungewöhnlich undurchsichtig, weil ImageService.uploadDocument ist @Transactional: die Verletzung rollt die ganze Methode zurück, wobei die Img-Reihe es hatte schon mit ihm geschrieben. Es gibt also keine fehlgeschlagene-Upload-Reihe, keine Teilung Zustand, und nichts in der Datenbank zeigt auf die Ursache - nur ein allgemeines Fehler. Die Diagnose bedeutete, das MIME-Gatter, die Verlängerung Whitelist, auszuschließen. mehrteilige Grenzen und die Proxy-Kette zuerst. imgs_client_mime_check erlaubt 0..35 gegen einen ImageMimeType, der genau 36 Werte. Vollständig. Der nächste MIME-Typ, den jemand hinzugefügt hätte, wäre kaputt gegangen EVERY Upload auf der Plattform und nicht eine Funktion, so wird es hier fallen gelassen auch, zusammen mit dem älteren handgeschriebenen check_client_mime (Decken 99) und dem sig_template_status-Prüfung, die mit 0..2 gleichermaßen voll ist. Gefallen statt verbreitet, was ************ ist bereits für die Rechte Tabellen und aus dem gleichen Grund: @Enumeriert Durchsetzung gültiger Werte in Java, so dass die Datenbankprüfung überflüssig ist, und Die Verbreiterung bewegt die Bombe nur, anstatt sie zu entschärfen. Bereits für die Produktion angewendet.