Hochgeladene Produktbilder für Azure Blob Storage optimieren

Identität von Quelle, Verarbeitung und Speicher modellieren

Ein hochgeladenes Produktfoto ist die Eingabe für einen Workflow und kein Veröffentlichungsereignis im Katalog. Authentifizieren Sie die hochladende Person, autorisieren Sie den Produktdatensatz, validieren Sie den erkannten Bildtyp und die Byte-Größe und legen Sie einen dauerhaften Verarbeitungsvorgang an, bevor Sie das Assembly-Ergebnis akzeptieren. Bewahren Sie die bearbeitbare oder hochauflösende Quelle unter einer ausdrücklichen Aufbewahrungsrichtlinie auf, statt anzunehmen, dass das WebP-Derivat sie ersetzen kann.

Geben Sie jedem Derivat eine Workflow-Version. Der Datensatz der Anwendung sollte das Produkt und die Quellversion diesem Workflow, seiner Assembly-ID sowie dem resultierenden Azure-Container und Blob-Pfad zuordnen. So kann eine spätere Qualitätsänderung ein neues Derivat erzeugen, ohne die geprüfte Version zu überschreiben oder den Weg zurück zu ihrer Quelle zu verlieren.

Das Azure-Template für Produktbilder erstellen

Das Template nimmt eine einzelne Datei über :original entgegen, übergibt sie an /image/resize und exportiert nur das resultierende WebP über /azure/store. Die Größenänderung mit der Strategie fit hält das vollständige Bild innerhalb des angeforderten Rahmens, während zoom mit dem Wert false verhindert, dass eine kleine Quelle vergrößert wird. Der versionierte Pfad enthält eine Produktkennung, die erst nach der Autorisierung durch die Anwendung bereitgestellt wird, sowie die Eindeutigkeit der Assembly.

Setzen Sie allow_steps_override auf false, damit ein Upload-Client das Ziel nicht ersetzen, keine größere Arbeitslast anfordern und die Verarbeitung nicht umgehen kann. Das Objekt auth im Template begrenzt die Anzahl und die Gesamtgröße der akzeptierten Uploads. Diese Grenzen verringern versehentliche Arbeitslast, doch die Anwendung muss weiterhin die Mandantenzugehörigkeit, den zulässigen Produktzustand, Rate Limits und einen erlaubten Wert für product_id durchsetzen.

{
  "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
    }
  }
}

Blob-Eigenschaften und Metadaten als Teil des Asset-Vertrags festlegen

Ein versioniertes WebP sollte den Workflow mit einem ausdrücklich angegebenen Content-Type verlassen. Das Beispiel verwendet während der Prüfung das Caching private, no-store, damit eine ablaufende SAS-Antwort nicht in einem gemeinsam genutzten Cache verbleibt. Da /azure/store cache_control auf den gespeicherten Blob schreibt, bleibt dieser Wert private, no-store am Objekt bestehen. Wenn derselbe Blob später mit einer Caching-Richtlinie ausgeliefert werden soll, müssen Sie dessen Cache-Control zurücksetzen oder ein neues Derivat erzeugen, statt anzunehmen, dass sich der Wert aus der Prüfphase von selbst aufhebt. Speichern Sie stabile, nicht sensible Metadaten wie den Workflow-Namen und die Kennung des Quelldatensatzes, wenn Betreiber einen Blob nachverfolgen müssen, ohne die Anwendungsdatenbank zu öffnen.

Legen Sie keine Geheimnisse, keine personenbezogenen Daten und keinen unbegrenzten Browser-Wert in Azure-Metadaten oder -Pfaden ab. Behandeln Sie product_id als validierte Kennung der Anwendung mit dokumentierter Zeichen- und Längenbegrenzung. /azure/store wandelt Metadatenwerte vom Typ String, Number und Boolean in Strings um, daher sollten nachgelagerte Systeme nicht erwarten, dass die ursprünglichen JSON-Typen erhalten bleiben.

Eine SAS-URL nur für eine kurzlebige Prüfung verwenden

/azure/store gibt die signierte URL im Feld sas_url des Ergebnisses zurück; das gewöhnliche Feld url ist unsigniert. Der Upload erzeugt auch dann eine SAS, wenn sas_expires_in weggelassen wird, und verwendet dabei eine serverseitige Standardlebensdauer. Wird sas_permissions weggelassen, gilt ein schreibfähiger Standardwert und kein ausschließlich lesender Zugriff. Dieses Beispiel setzt sas_permissions ausdrücklich auf r und sas_expires_in auf 900 Sekunden. Setzen Sie beide Werte, statt sich für den Prüfzugriff auf Standardwerte zu verlassen.

Der Robot konfiguriert keinen anonymen Zugriff. Halten Sie den Ziel-Container privat und prüfen Sie die Einstellung AllowBlobPublicAccess des Speicherkontos; wird anonymer Zugriff auf Kontoebene untersagt, überschreibt das die Container-Einstellungen. Wer die SAS-URL erhält, kann deren delegierten Zugriff während der Gültigkeitsdauer nutzen. Protokollieren Sie sie daher nicht, nehmen Sie sie nicht in Analytics auf, senden Sie sie nicht an unbeteiligte Clients und speichern Sie sie nicht als dauerhafte URL des Katalog-Assets.

Speichern Sie den Container und den Blob-Pfad dauerhaft als Identität. Wenn eine prüfende Person später Zugriff benötigt, sollte die Anwendung diese Anfrage autorisieren und den Zugriff gemäß ihrem aktuellen Auslieferungskonzept ausstellen oder beschaffen. Ein erfolgreicher SAS-Abruf belegt, dass das Objekt mit diesem Token gelesen werden kann; er genehmigt das Asset nicht, erteilt keine Veröffentlichung im Katalog und ersetzt keine Autorisierung auf Produktebene.

Bildverhalten vor der Katalogumstellung überprüfen

Der Step für die Größenänderung setzt strip auf true, wodurch alle eingebetteten Metadaten einschließlich des ICC-Farbprofils aus dem Derivat entfernt werden. Testen Sie die EXIF-Ausrichtung, breite und hohe Bilder, transparente Eingaben, das Verhalten von Farbprofilen, sehr kleine Quellen, sehr große Abmessungen, Animationen und fehlerhafte Daten. Vergleichen Sie die gerenderte Ausgabe sowie deren MIME-Typ, Abmessungen, Byte-Größe und Speicher-Metadaten. Das Entfernen des Profils und die WebP-Konvertierung können jeweils die gerenderte Farbe oder anderes erforderliches Verhalten beeinflussen.

Prüfen Sie, ob die Azure-Konto- und Container-Einstellungen anonyme Lesezugriffe auf den Prüf-Blob verhindern. Gleichen Sie den erfolgreichen Export mit dem erwarteten Produktvorgang ab und überführen Sie den Katalogdatensatz anschließend über einen separaten autorisierten Übergang. Rollen Sie zuerst für eine kleine Traffic-Kohorte aus, beobachten Sie das Auslieferungs- und Cache-Verhalten und behalten Sie das vorherige Derivat, bis das Rollback-Fenster schließt.

Wiederherstellen, ohne Duplikate zu veröffentlichen

Ein Timeout oder ein verpasster Webhook ist ein ungewisses Ergebnis und kein Beleg dafür, dass der Blob nicht geschrieben wurde. Speichern Sie den Vorgang, bevor Sie die Assembly erstellen, und verarbeiten Sie signierte Abschlussbenachrichtigungen idempotent. Wenn die aufrufende Seite die Antwort verliert, prüfen Sie die vorhandene Assembly und den Datensatz der Anwendung, bevor Sie einen weiteren Lauf starten.

Klassifizieren Sie Fehler nach Aufnahme, Bildverarbeitung, Azure-Authentifizierung, fehlendem Container und Export. Stellen Sie Betreibern stabile Wiederherstellungsaktionen bereit und halten Sie dabei unverarbeitete Anbieterdetails geschützt. Ein neuer Workflow-Lauf sollte ein neues versioniertes Objekt erzeugen und den Katalog erst nach der Prüfung aktualisieren; das Löschen des alten Blobs gehört zu einem späteren Aufbewahrungsauftrag.