Optimiser les images de produits téléversées pour Azure Blob Storage

Modéliser l’identité de la source, du traitement et du stockage

Une photo de produit téléversée est une entrée du flux de travail, pas un événement de publication dans le catalogue. Authentifiez la personne qui téléverse le fichier, autorisez l’accès à la fiche produit, validez le type d’image détecté et la taille en octets, et créez une opération de traitement durable avant d’accepter le résultat de l’Assembly. Conservez la source modifiable ou haute résolution selon une politique de conservation explicite plutôt que de supposer que le dérivé WebP peut la remplacer.

Associez chaque dérivé à une version du flux de travail. L’enregistrement de l’application devrait relier le produit et la version de la source à ce flux de travail, à son identifiant d’Assembly ainsi qu’au conteneur Azure et au chemin du blob obtenus. Une modification ultérieure de la qualité peut ainsi créer un nouveau dérivé sans écraser la version examinée ni perdre le lien vers sa source.

Construire le Template d’images de produits pour Azure

Le Template accepte un seul fichier via :original, l’envoie à /image/resize et exporte uniquement le WebP obtenu via /azure/store. Le redimensionnement avec ajustement maintient l’image entière dans le cadre demandé, tandis que zoom défini sur false empêche l’agrandissement d’une petite source. Le chemin versionné contient un identifiant de produit fourni uniquement après autorisation de l’application, ainsi qu’un élément garantissant l’unicité de l’Assembly.

Définissez allow_steps_override sur false pour qu’un client de téléversement ne puisse ni remplacer la destination, ni demander une charge de travail plus importante, ni contourner le traitement. L’objet auth du Template limite le nombre et la taille totale des téléversements acceptés. Ces limites réduisent la charge de travail accidentelle, mais l’application doit toujours faire respecter l’appartenance au locataire, l’état autorisé du produit, les limites de débit et une valeur autorisée pour product_id.

{
  "allow_steps_override": false,
  "auth": {
    "max_number_of_files": 1,
    "max_size": 52428800
  },
  "steps": {
    ":original": {
      "robot": "/upload/handle"
    },
    "product_webp": {
      "use": ":original",
      "robot": "/image/resize",
      "width": 1600,
      "height": 1600,
      "resize_strategy": "fit",
      "zoom": false,
      "format": "webp",
      "quality": 82,
      "strip": true
    },
    "azure_review": {
      "use": "product_webp",
      "robot": "/azure/store",
      "credentials": "azure-product-images",
      "path": "catalog/web-v1/${fields.product_id}/${assembly.id}/${file.url_name}",
      "content_type": "image/webp",
      "cache_control": "private, no-store",
      "metadata": {
        "workflow": "catalog-web-v1",
        "source_id": "${fields.product_id}"
      },
      "sas_expires_in": 900,
      "sas_permissions": "r",
      "result": true
    }
  }
}

Définir les propriétés et les métadonnées du blob dans le contrat de la ressource

Un WebP versionné devrait sortir du flux de travail avec un Content-Type explicite. L’exemple utilise la politique de cache private, no-store pendant l’examen afin qu’un cache partagé ne conserve pas une réponse SAS dont la validité expire. Comme /azure/store écrit cache_control sur le blob stocké, cette valeur private, no-store persiste sur l’objet. Pour diffuser ultérieurement le même blob avec une politique de mise en cache, il faut redéfinir son Cache-Control ou produire un nouveau dérivé, plutôt que de supposer que la valeur utilisée pendant l’examen s’efface d’elle-même. Enregistrez des métadonnées stables et non sensibles, telles que le nom du flux de travail et l’identifiant de l’enregistrement source, lorsque les opérateurs doivent retracer l’origine d’un blob sans ouvrir la base de données de l’application.

Ne placez ni secrets, ni informations personnelles, ni valeur de navigateur sans limites définies dans les métadonnées ou les chemins Azure. Traitez product_id comme un identifiant d’application validé, avec des limites documentées de caractères et de longueur. /azure/store convertit les valeurs de métadonnées de type chaîne, nombre et booléen en chaînes ; les consommateurs ne devraient donc pas s’attendre à ce que les types JSON d’origine soient préservés.

Utiliser une URL SAS uniquement pour un examen de courte durée

/azure/store renvoie l’URL signée dans le champ sas_url du résultat ; le champ url ordinaire n’est pas signé. Le téléversement crée un SAS même lorsque sas_expires_in est omis, avec la durée de validité par défaut du serveur. Si sas_permissions est omis, la valeur par défaut autorise l’écriture et ne fournit pas un accès en lecture seule. Cet exemple définit explicitement sas_permissions sur r et sas_expires_in sur 900 secondes. Définissez les deux valeurs plutôt que de vous fier aux valeurs par défaut pour l’accès d’examen.

Le Robot ne configure pas l’accès anonyme. Maintenez le conteneur de destination privé et vérifiez le paramètre AllowBlobPublicAccess du compte de stockage ; l’interdiction de l’accès anonyme au niveau du compte prévaut sur les paramètres du conteneur. Toute personne qui obtient l’URL SAS peut utiliser l’accès qu’elle délègue pendant sa période de validité. Ne la consignez donc pas dans les journaux, ne l’incluez pas dans les données analytiques, ne l’envoyez pas à des clients sans rapport avec l’opération et ne l’enregistrez pas comme URL permanente de la ressource du catalogue.

Enregistrez le conteneur et le chemin du blob comme identité durable. Lorsqu’un examinateur a besoin d’un accès ultérieur, l’application devrait autoriser cette demande et émettre ou obtenir un accès conformément à son mode de diffusion actuel. Une récupération réussie via SAS prouve que l’objet est lisible avec ce jeton ; elle n’approuve pas la ressource, n’autorise pas sa publication dans le catalogue et ne remplace pas l’autorisation au niveau du produit.

Vérifier le comportement des images avant la bascule du catalogue

Le Step de redimensionnement définit strip sur true, ce qui supprime du dérivé toutes les métadonnées intégrées, y compris le profil colorimétrique ICC. Testez l’orientation EXIF, les images larges et hautes, les entrées transparentes, le comportement des profils colorimétriques, les très petites sources, les très grandes dimensions, l’animation et les données malformées. Comparez le rendu de sortie ainsi que son type MIME, ses dimensions, sa taille en octets et ses métadonnées de stockage. La suppression du profil et la conversion WebP peuvent chacune affecter les couleurs du rendu ou d’autres comportements requis.

Vérifiez que les paramètres du compte et du conteneur Azure empêchent la lecture anonyme du blob à examiner. Réconciliez l’exportation réussie avec l’opération produit attendue, puis faites évoluer la fiche du catalogue par une transition autorisée distincte. Déployez d’abord sur une petite cohorte du trafic, observez le comportement de la diffusion et du cache, et conservez le dérivé précédent jusqu’à la fermeture de la fenêtre de retour en arrière.

Reprendre après un échec sans publier de doublons

Un délai d’attente dépassé ou un webhook manqué laisse l’issue incertaine ; il ne prouve pas que le blob n’a pas été écrit. Enregistrez l’opération avant de créer l’Assembly et traitez les notifications de fin signées de manière idempotente. Si l’appelant perd la réponse, inspectez l’Assembly existante et l’enregistrement de l’application avant de lancer une autre exécution.

Classez les échecs selon qu’ils concernent la réception, le traitement des images, l’authentification Azure, l’absence de conteneur ou l’exportation. Proposez aux opérateurs des actions de reprise stables tout en protégeant les détails bruts du fournisseur. Une nouvelle exécution du flux de travail devrait créer un nouvel objet versionné et ne mettre à jour le catalogue qu’après examen ; la suppression de l’ancien blob relève d’une tâche ultérieure de gestion de la conservation.