Wichtigste Erkenntnisse
- Autorisieren und validieren Sie die hochladende Person, bevor Sie eine Assembly erstellen; eine erfolgreiche Bildverarbeitung ist keine Moderationsfreigabe.
- Entfernen Sie eingebettete Metadaten aus dem Auslieferungsderivat und bewahren Sie erforderliche Quellnachweise unter einer separaten Aufbewahrungsrichtlinie auf.
- Verwenden Sie einen eindeutigen Pfad mit asset_id und assembly.id, damit Wiederholungsversuche geprüfte Bilder nicht überschreiben können; kombinieren Sie ihn mit einer Deduplizierungsprüfung in der Anwendung.
Eine Pipeline für nutzergenerierte Bilder braucht mehr als günstigen Objektspeicher. Die Anwendung muss wissen, welcher Upload angenommen wurde, welche Derivat-Richtlinie ausgeführt wurde, wo das Ergebnis liegt und ob es ausgeliefert werden darf. Kollisionsfreie Backblaze-Pfade und ein eng gefasster Application Key halten Wiederholungsversuche beim Speichern von Moderation und Produktzustand getrennt.
Worauf es besonders ankommt
- Beschränken Sie den Standard-Application-Key von B2 auf den Ziel-Bucket und ein stabiles Ausgabepräfix wie community/web-v1/, das alle Pfade abdeckt, die das Template erzeugt.
- Verwenden Sie X-Bz-Info-*-Header für stabile Workflow-Labels, nicht für private Nutzerdaten oder beliebige, nicht codierte Dateinamen.
- Liefern oder autorisieren Sie das fertige Objekt über die Auslieferungsschicht der Anwendung, statt die URL des Speicherergebnisses als Berechtigungsmodell des Produkts zu behandeln.
Moderation und Verarbeitung als getrennte Zustände führen
Ein gültiges Bild ist nicht zwangsläufig ein Inhalt, den das Produkt zugänglich machen sollte. Erfassen Sie die hochladende Person, den Mandanten, die Quell-Prüfsumme, den Moderationszustand und den Verarbeitungsvorgang, bevor Sie die Assembly starten. Der Bild-Workflow kann Pixel normalisieren und eingebettete Metadaten entfernen, aber die Anwendung muss entscheiden, ob Motiv, Eigentümerschaft und Kontext ihrer Richtlinie entsprechen.
Halten Sie Zustände wie hochgeladen, in Verarbeitung, Prüfung erforderlich, freigegeben, abgelehnt und Export fehlgeschlagen klar auseinander. Markieren Sie Inhalte nicht als freigegeben, nur weil /image/resize und /backblaze/store erfolgreich waren, und machen Sie aus einem Verarbeitungsfehler keine Moderationsablehnung. Jeder Zustand braucht sein eigenes Verhalten bei Wiederholungsversuchen, Prüfung und Aufbewahrung.
Das versionierte Backblaze-Template für Bilder erstellen
Das Template nimmt einen einzelnen begrenzten Upload entgegen, erstellt ein WebP-Derivat, das in die gewählten Abmessungen passt, entfernt eingebettete Bildmetadaten und exportiert nur dieses Derivat. zoom ist false, sodass eine kleinere Quelle kleiner bleibt. Der Zielpfad enthält eine Versionsbezeichnung und assembly.id, sodass jede Assembly einen kollisionsfreien Pfad erzeugt, statt ein zuvor geprüftes Bild zu überschreiben.
Die Anwendung liefert eine validierte asset_id, wählt aber weder Zugangsdaten noch Bucket, beliebiges Präfix oder Robot-Parameter aus. Belassen Sie allow_steps_override auf false und nutzen Sie die auth-Limits des Templates als abschließende Grenze für die Arbeitslast. Bewahren Sie ein Original separat auf, wenn Einsprüche, erneute Verarbeitung oder rechtliche Anforderungen Quellnachweise erfordern; strip wirkt sich auf das Derivat aus, nicht auf ein externes Quellarchiv.
{
"allow_steps_override": false,
"auth": {
"max_number_of_files": 1,
"max_size": 26214400
},
"steps": {
":original": {
"robot": "/upload/handle"
},
"community_webp": {
"use": ":original",
"robot": "/image/resize",
"width": 2048,
"height": 2048,
"resize_strategy": "fit",
"zoom": false,
"format": "webp",
"quality": 80,
"strip": true
},
"backblaze_versioned": {
"use": "community_webp",
"robot": "/backblaze/store",
"credentials": "backblaze-community-images",
"path": "community/web-v1/${fields.asset_id}/${assembly.id}/${file.url_name}",
"headers": {
"X-Bz-Info-workflow": "community-web-v1"
},
"result": true
}
}
}Den Backblaze-Application-Key einschränken
Erstellen Sie einen Standard-Application-Key, statt den Master Key zu verwenden. Beschränken Sie ihn auf den Ziel-Bucket und ein stabiles Ausgabepräfix wie community/web-v1/, das alle Pfade abdeckt, die das Template erzeugt. Die Dokumentation zum Backblaze-Speicher-Robot verlangt listBuckets, writeFiles und listFiles, damit der Robot den Bucket auflösen und das Objekt hochladen kann.
Eine Präfixbeschränkung und eindeutige Zielpfade verringern die Auswirkungen, wenn die Zugangsdaten offengelegt werden, autorisieren aber keine Nutzer der Anwendung und moderieren keine Inhalte. Hinterlegen Sie Bucket, Application-Key-ID und Application Key in benannten Template-Zugangsdaten. Wechseln oder widerrufen Sie diese Zugangsdaten unabhängig von den Anmeldesitzungen der Anwendung und testen Sie den Ersatz, bevor Sie den alten Schlüssel entfernen.
Bucket-Grenze
Der Schlüssel kann in nicht zugehörigen Buckets nicht agieren.
Präfix-Grenze
Der Schlüssel ist auf Objekte unterhalb des Derivat-Namensraums beschränkt.
Anwendungsgrenze
Das Produkt entscheidet weiterhin, welcher Mandant und welches Asset das Template aufrufen dürfen.
Pfade und Dateiinformationen bewusst einsetzen
Objektnamen in Backblaze B2 bilden einen flachen Namensraum, auch wenn Werkzeuge durch Schrägstriche getrennte Präfixe als Ordner darstellen. Nutzen Sie diese Präfixe zur Organisation und zur Schlüsselbeschränkung, nicht als Beleg dafür, dass übergeordnete Verzeichnisse existieren. Nehmen Sie eine Workflow-Version und einen begrenzten Anwendungsbezeichner in den Pfad auf und verwenden Sie assembly.id, um Namenskollisionen zu vermeiden.
/backblaze/store akzeptiert Header mit Zeichenkettenwerten, einschließlich Dateiinformationen vom Typ X-Bz-Info-*. Verwenden Sie stabile Bezeichnungen wie die Workflow-Version des Derivats. Fügen Sie keine privaten Nutzerdaten, keine Geheimnisse und keinen unbegrenzten Originaldateinamen ein. Der Robot lehnt einen erzeugten Dateinamen ab, der länger als 1.024 UTF-8-Bytes ist; deshalb muss jedes Anwendungsfeld, das in den Pfad einfließt, einen Vertrag über Länge und Zeichen haben.
Fehlermodell von Derivat und Ziel testen
Testen Sie Ausrichtung, Transparenz, Animation, Farbprofile, große Abmessungen, fehlerhafte Dateien, doppelte Einreichungen, ungültige Application Keys, einen Schlüssel, der auf das falsche Präfix beschränkt ist, und einen nicht verfügbaren Bucket. Prüfen Sie Aussehen, Format, Abmessungen, Bytes, das Entfernen der Metadaten, den Objektpfad und die Dateiinformationen, statt sich allein auf eine grüne Assembly zu verlassen.
Erfassen Sie Fehler getrennt nach Datenaufnahme, Verarbeitung, Authentifizierung, Bucket-Auflösung und Upload. Ein unklarer Timeout sollte in den Abgleich übergehen, weil das Objekt bereits existieren kann. Prüfen Sie die ursprüngliche Assembly und den Vorgangsdatensatz, bevor Sie einen neuen versionierten Pfad anlegen, sonst kann das Produkt mehrere scheinbar freigegebene Derivate für eine Quelle ansammeln.
Speicher-URLs von der Auslieferungsautorisierung getrennt halten
Eine Ergebnis-URL benennt, was der Speicher-Step zurückgegeben hat; sie ist weder der Mandant der Anwendung noch deren Moderationsrichtlinie. Halten Sie das Objekt für abnehmende Systeme des Produkts unzugänglich, bis die Anwendung es mit dem erwarteten Vorgang abgeglichen und den Moderationszustand weitergeführt hat. Liefern Sie über die für das Produkt gewählte Bucket- und CDN-Konfiguration aus, wobei die Autorisierung an dieser Grenze greift.
Bewahren Sie den dauerhaften Bucket- und Objektnamen, die Workflow-Version, die Assembly-ID, die Quellidentität und die Moderationsentscheidung auf. Löschen Sie abgelehnte oder abgelöste Derivate über einen separaten Aufbewahrungsprozess, der die Dateiversionen von Backblaze und die Audit-Anforderungen des Produkts kennt. Das verarbeitende Template sollte diese destruktive Entscheidung nicht treffen.
Wissenswerte technische Details
- /backblaze/store benötigt Werte für Bucket, Application-Key-ID und Application Key, die über benannte Template-Zugangsdaten bereitgestellt werden können.
- Die Dokumentation zu /backblaze/store gibt an, dass für den Bucket die Berechtigung listBuckets erforderlich ist, um seine ID aufzulösen, zusätzlich zu writeFiles und listFiles.
- Standard-Application-Keys von Backblaze lassen sich auf einen Bucket und ein Dateinamenpräfix beschränken; das Präfix muss den vom Template erzeugten Pfad abdecken.
- /backblaze/store akzeptiert einen Pfad mit Assembly Variables und ein headers-Objekt mit Zeichenkettenwerten. Header vom Typ X-Bz-Info-* werden zu Dateiinformationen in Backblaze.
- Objektnamen in Backblaze B2 sind flache Zeichenketten; durch Schrägstriche getrennte Ordner sind Präfixe, die von Werkzeugen und Oberflächen als Hierarchie dargestellt werden.
- Der Robot lehnt erzeugte Backblaze-Dateinamen ab, die länger als 1.024 UTF-8-Bytes sind; die Grenze zählt codierte Bytes, keine Zeichen.
Ein praxisnaher Ansatz
- 1
Legen Sie Upload-Limits, Moderationszustände, Zielformat, Metadatenrichtlinie und ein stabiles Zielpräfix fest.
- 2
Erstellen Sie einen präfixbeschränkten Backblaze-Application-Key und speichern Sie ihn als benannte Template-Zugangsdaten.
- 3
Führen Sie repräsentative mobile, transparente, animierte, fehlerhafte und metadatenreiche Bild-Fixtures aus.
- 4
Speichern Sie die B2-Objektidentität dauerhaft, bevor Sie den Anwendungszustand ändern, und führen Sie Wiederholungen pro Vorgang statt pro Dateiname durch.
Wann Transloadit hilfreich ist
Verwenden Sie /upload/handle für einen moderierten Aufnahmekandidaten, /image/resize für ein begrenztes, von Metadaten bereinigtes WebP und /backblaze/store für einen eindeutigen, versionierten Pfad. Verwenden Sie einen Standard-Application-Key von B2, der auf den Ziel-Bucket und ein stabiles Ausgabepräfix beschränkt ist, und legen Sie stabile Workflow-Metadaten in X-Bz-Info-*-Headern ab.
Architekturgrenze
Transloadit nimmt ein Community-Bild entgegen, erstellt die speichereffiziente Variante und schreibt sie in einen Backblaze-B2-Bucket. Die Anwendung bleibt verantwortlich für Moderation, Mandantenzugehörigkeit, dauerhafte Quelldatensätze, Bucket-Richtlinie, Autorisierung der Auslieferung und Löschung.
Häufig gestellte Fragen
Moderiert das Entfernen von Metadaten das Bild?
Nein. Dabei werden eingebettete Metadaten aus dem Derivat entfernt. Inhaltsrichtlinie, Eigentümerschaft und kontextbezogene Prüfung bleiben in der Verantwortung der Anwendung.
Sollte der Workflow einen Master-Application-Key von Backblaze verwenden?
Nein. Verwenden Sie einen Standard-Application-Key, der auf den Ziel-Bucket und ein Derivat-Präfix beschränkt ist, das alle erzeugten Pfade abdeckt, mit den Capabilities, die der Robot benötigt.
Sind mit Schrägstrichen getrennte Pfade echte B2-Ordner?
Nein. B2 speichert flache Objektnamen. Oberflächen können gemeinsame Präfixe als Ordner darstellen, was für die Organisation und die Zugriffsbeschränkung nützlich ist.
Dürfen X-Bz-Info-Header Nutzerdaten enthalten?
Vermeiden Sie das. Verwenden Sie begrenzte, nicht sensible betriebliche Labels und halten Sie private Nutzerdaten oder Moderationsdaten in der Datenbank der Anwendung.
Warum nicht das vorherige Derivat überschreiben?
Eindeutige, versionierte Pfade erleichtern den Abgleich von Wiederholungsversuchen, Moderationsnachweisen, Rollbacks und Cache-Verhalten. Kombinieren Sie sie mit einer Deduplizierungsprüfung in der Anwendung und löschen Sie abgelöste Versionen später gemäß einer expliziten Aufbewahrungsrichtlinie.