Points clés à retenir
- Autorisez et validez l’utilisateur qui téléverse avant de créer une Assembly ; la réussite du traitement d’une image ne vaut pas approbation de modération.
- Supprimez les métadonnées intégrées du dérivé destiné à la diffusion tout en conservant les éléments de preuve source requis selon une politique de conservation distincte.
- Utilisez un chemin unique avec asset_id et assembly.id pour que les nouvelles tentatives ne puissent pas écraser les images examinées ; associez-le à un contrôle de déduplication dans l’application.
Un pipeline d’images générées par les utilisateurs a besoin de plus qu’un stockage objet peu coûteux. L’application doit savoir quel téléversement a été accepté, quelle politique de création de dérivés a été appliquée, où se trouve le résultat et si sa diffusion est autorisée. Des chemins Backblaze sans collision et une clé d’application à portée restreinte permettent de séparer les nouvelles tentatives de stockage de la modération et de l’état du produit.
L’essentiel
- Limitez la clé d’application standard B2 au bucket de destination et à un préfixe de sortie stable, tel que community/web-v1/, qui couvre tous les chemins générés par le Template.
- Utilisez les en-têtes X-Bz-Info-* pour des libellés stables du flux de travail, et non pour des données privées des utilisateurs ou des noms de fichiers arbitraires non encodés.
- Diffusez l’objet final ou autorisez son accès par la couche de diffusion de l’application au lieu de traiter l’URL du résultat de stockage comme le modèle d’autorisations du produit.
Séparer les états de modération et de traitement
Une image valide n’est pas nécessairement un contenu que le produit devrait rendre accessible. Enregistrez l’utilisateur qui téléverse, le locataire, la somme de contrôle de la source, l’état de modération et l’opération de traitement avant de démarrer l’Assembly. Le flux de travail d’images peut normaliser les pixels et supprimer les métadonnées intégrées, mais l’application doit décider si le sujet, la propriété et le contexte respectent sa politique.
Gardez distincts les états tels que téléversé, en cours de traitement, examen requis, approuvé, rejeté et échec de l’exportation. Ne marquez pas le contenu comme approuvé au seul motif que /image/resize et /backblaze/store ont réussi, et ne transformez pas une erreur de traitement en rejet de modération. Chaque état nécessite son propre comportement pour les nouvelles tentatives, l’examen et la conservation.
Créer le Template d’images versionnées pour Backblaze
Le Template accepte un seul téléversement soumis à des limites, crée un dérivé WebP qui respecte les dimensions choisies, supprime les métadonnées intégrées à l’image et exporte uniquement ce dérivé. zoom vaut false, donc une source plus petite reste plus petite. Le chemin de destination contient un libellé de version et assembly.id, de sorte que chaque Assembly génère un chemin sans collision au lieu d’écraser une image précédemment examinée.
L’application fournit une valeur validée pour asset_id, mais ne choisit ni ensemble d’informations d’identification, ni bucket, ni préfixe arbitraire, ni paramètres de Robot. Conservez allow_steps_override à false et utilisez les limites auth du Template comme limite finale de la charge de travail. Conservez séparément un original lorsque les recours, le retraitement ou les exigences légales nécessitent des éléments de preuve source ; strip affecte le dérivé, pas une archive source externe.
{
"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
}
}
}Restreindre la clé d’application Backblaze
Créez une clé d’application standard plutôt que d’utiliser la clé principale. Limitez-la au bucket de destination et à un préfixe de sortie stable, tel que community/web-v1/, qui couvre tous les chemins générés par le Template. La documentation du Robot de stockage Backblaze exige listBuckets, writeFiles et listFiles pour que le Robot puisse retrouver le bucket et téléverser l’objet.
Une restriction de préfixe et des chemins de destination uniques réduisent l’impact en cas d’exposition des informations d’identification, mais n’autorisent pas un utilisateur de l’application et ne modèrent pas le contenu. Enregistrez le bucket, l’identifiant de la clé d’application et la clé d’application dans un ensemble nommé d’informations d’identification de Template. Renouvelez ou révoquez cet ensemble d’informations d’identification indépendamment des sessions de connexion à l’application et testez son remplacement avant de supprimer l’ancienne clé.
Périmètre du bucket
La clé ne peut pas agir sur des buckets sans rapport.
Périmètre du préfixe
La clé est limitée aux objets de l’espace de noms des dérivés.
Périmètre de l’application
Le produit décide toujours pour quel locataire et quelle ressource le Template peut être invoqué.
Utiliser les chemins et les informations des fichiers à bon escient
Les noms d’objets Backblaze B2 forment un espace de noms sans hiérarchie, même lorsque les outils présentent les préfixes séparés par des barres obliques comme des dossiers. Utilisez ces préfixes pour l’organisation et la restriction des clés, et non comme preuve de l’existence de répertoires parents. Incluez une version du flux de travail et un identifiant d’application de longueur limitée dans le chemin, et utilisez assembly.id pour éviter les collisions de noms.
/backblaze/store accepte des en-têtes dont les valeurs sont des chaînes de caractères, notamment les informations de fichier X-Bz-Info-*. Utilisez des libellés stables, tels que la version du flux de travail de création des dérivés. N’insérez pas de données privées des utilisateurs, de secrets ou de nom de fichier d’origine sans limite de longueur. Le Robot rejette tout nom de fichier généré dépassant 1 024 octets en UTF-8, donc chaque champ de l’application utilisé dans le chemin doit respecter un contrat de longueur et de caractères.
Tester le dérivé et le modèle de défaillance de la destination
Testez l’orientation, la transparence, l’animation, les profils colorimétriques, les grandes dimensions, les fichiers malformés, les soumissions dupliquées, les clés d’application non valides, une clé limitée au mauvais préfixe et un bucket indisponible. Examinez l’apparence, le format, les dimensions, le nombre d’octets, la suppression des métadonnées, le chemin de l’objet et les informations du fichier plutôt que de vous contenter d’une Assembly au vert.
Suivez les échecs par catégorie : réception, traitement, authentification, recherche du bucket et téléversement. Un dépassement de délai dont l’issue est incertaine devrait déclencher une réconciliation, car l’objet peut déjà exister. Vérifiez l’Assembly d’origine et l’enregistrement de l’opération avant de créer un nouveau chemin versionné, sinon le produit risque d’accumuler plusieurs dérivés qui semblent approuvés pour une même source.
Séparer les URL de stockage de l’autorisation de diffusion
Une URL de résultat identifie ce que le Step de stockage a renvoyé ; elle ne constitue pas la politique de l’application relative aux locataires ou à la modération. Gardez l’objet inaccessible aux consommateurs du produit jusqu’à ce que l’application le réconcilie avec l’opération attendue et fasse progresser l’état de modération. Diffusez-le au moyen de la configuration du bucket et du CDN choisie pour le produit, en appliquant l’autorisation à cette frontière.
Conservez le bucket et le nom de l’objet stocké durablement, la version du flux de travail, l’identifiant de l’Assembly, l’identité de la source et la décision de modération. Supprimez les dérivés rejetés ou remplacés au moyen d’un processus de conservation distinct qui tient compte des versions de fichiers Backblaze et des exigences d’audit du produit. Le Template de traitement ne devrait pas prendre cette décision destructive.
Détails techniques à connaître
- /backblaze/store exige les valeurs du bucket, de l’identifiant de la clé d’application et de la clé d’application, qui peuvent être fournies au moyen d’un ensemble nommé d’informations d’identification de Template.
- Pour /backblaze/store, la clé d’application doit disposer de l’autorisation listBuckets pour retrouver l’identifiant du bucket, ainsi que de writeFiles et de listFiles.
- Les clés d’application standard Backblaze peuvent être limitées à un bucket et à un préfixe de nom de fichier ; ce préfixe doit couvrir le chemin généré par le Template.
- /backblaze/store accepte un chemin contenant des Assembly Variables et un objet headers dont les valeurs sont des chaînes de caractères. Les en-têtes X-Bz-Info-* deviennent des informations de fichier Backblaze.
- Les noms d’objets Backblaze B2 sont des chaînes sans hiérarchie ; les dossiers délimités par des barres obliques sont des préfixes présentés sous forme de hiérarchie par les outils et les interfaces.
- Le Robot rejette les noms de fichiers Backblaze générés dépassant 1 024 octets en UTF-8 ; la limite porte sur les octets encodés, pas sur les caractères.
Une approche pratique
- 1
Définissez les limites de téléversement, les états de modération, le format cible, la politique de métadonnées et un préfixe de destination stable.
- 2
Créez une clé d’application Backblaze limitée à un préfixe et enregistrez-la dans un ensemble nommé d’informations d’identification de Template.
- 3
Exécutez les tests avec des images représentatives provenant d’appareils mobiles, transparentes, animées, malformées et riches en métadonnées.
- 4
Enregistrez durablement l’identité de l’objet B2 avant de modifier l’état de l’application, et effectuez les nouvelles tentatives par opération plutôt que par nom de fichier.
Quand Transloadit est utile
Utilisez /upload/handle pour une seule image candidate soumise à modération à l’entrée, /image/resize pour un WebP aux dimensions limitées et sans métadonnées, et /backblaze/store pour un chemin versionné unique. Utilisez une clé d’application standard B2 limitée au bucket de destination et à un préfixe de sortie stable, et placez les métadonnées stables du flux de travail dans les en-têtes X-Bz-Info-*.
Périmètre architectural
Transloadit accepte une image de la communauté, crée une déclinaison économe en espace de stockage et l’écrit dans un bucket Backblaze B2. L’application reste responsable de la modération, de l’appartenance au locataire, des enregistrements sources durables, de la politique du bucket, de l’autorisation de diffusion et de la suppression.
Questions fréquentes
La suppression des métadonnées assure-t-elle la modération de l’image ?
Non. Elle retire les métadonnées intégrées du dérivé. La politique de contenu, la propriété et l’examen contextuel restent sous la responsabilité de l’application.
Le flux de travail doit-il utiliser une clé d’application principale Backblaze ?
Non. Utilisez une clé standard restreinte au bucket de destination et à un préfixe de dérivés couvrant tous les chemins générés, avec les capacités requises par le Robot.
Les chemins séparés par des barres obliques sont-ils de véritables dossiers B2 ?
Non. B2 stocke les noms d’objets dans un espace sans hiérarchie. Les interfaces peuvent présenter les préfixes communs comme des dossiers, ce qui facilite l’organisation et la restriction des accès.
Les en-têtes X-Bz-Info peuvent-ils contenir des données utilisateur ?
Évitez cela. Utilisez des libellés opérationnels de taille limitée et non sensibles, et conservez les données privées des utilisateurs ou de modération dans la base de données de l’application.
Pourquoi ne pas écraser le dérivé précédent ?
Des chemins versionnés uniques facilitent la réconciliation des nouvelles tentatives, des éléments de preuve de modération, des retours à une version antérieure et du comportement du cache. Associez-les à un contrôle de déduplication dans l’application, puis supprimez ultérieurement les versions remplacées selon une politique de conservation explicite.