SafeStage: Mail-, App- und Checkout-Schutz für Staging

SafeStage einrichten und prüfen

1. Installation: Installiere und aktiviere SafeStage unter Erweiterungen > Meine Erweiterungen. Öffne im Menü der Erweiterung die Konfiguration. Speichere Änderungen über Speichern.
2. Geltungsbereich: Wähle zuerst Alle Verkaufskanäle, um die globalen Werte festzulegen. Aktiviere unter Safety Mode den Schalter SafeStage aktivieren. Für Mail, Storefront, Robots und Payment Guard sind danach Verkaufskanal-Overrides möglich. Administration-Banner und Outbound Guard lesen ausschließlich die globalen Werte.
3. Mail Guard: Aktiviere Mail Guard aktivieren. Trage unter Redirect-Empfänger gültige QA-Adressen ein, jeweils eine je Zeile oder kommagetrennt. Ersetze den Beispielwert qa@example.test durch dein echtes Testpostfach. Ohne gültiges Umleitungsziel werden Mails mit nicht erlaubten Empfängern vollständig blockiert.
4. Mail-Regeln: Lege den Betreff-Präfix fest. Aktiviere bei Bedarf CC- und BCC-Empfänger entfernen und Ursprüngliche Empfänger protokollieren. Die Zieladressen im Log werden maskiert; Betreffzeilen bleiben lesbar. Verwende dort keine personenbezogenen Inhalte.
5. Empfänger-Freigabe: Unter Erlaubte Empfänger und Domains sind einzelne Adressen, Domains wie @agency.test und Muster wie *.internal.test möglich. Das Mail-Muster erlaubt die Basisdomain und ihre Subdomains. Erlaubte Hauptempfänger erhalten die Mail weiterhin. Bei deaktivierter CC/BCC-Entfernung bleiben nur erlaubte CC/BCC-Empfänger erhalten. Jede Freigabe muss bewusst gewählt sein.
6. Banner und Indexierung: Aktiviere Storefront-Banner anzeigen. Leere Bannertexte verwenden übersetzte Standardtexte. Administration-Banner anzeigen und dessen Text werden global gepflegt. Lade die Administration nach dem Speichern neu, um den Bannerstatus zu aktualisieren. Aktiviere Noindex-Schutz aktivieren und bei Bedarf Alles in robots.txt sperren. Prüfe die echte HTTP-Antwort; eine vom Webserver statisch ausgelieferte robots.txt wird nicht durch den Plugin-Antwortschutz ersetzt. Bei mehreren Verkaufskanälen auf demselben Host und Port kann die robots.txt-Sperre den gemeinsamen Host betreffen.
7. Outbound Guard: Bleibe bei Alle Verkaufskanäle. Aktiviere Outbound Guard aktivieren. Der Schutz gilt für den Shopware-App-System-HTTP-Client, einschließlich der darüber ausgeführten App-Webhooks und App-Flow-Aktionen. Eigene HTTP-Clients anderer Plugins werden nicht erfasst.
8. Outbound-Modus: Wähle unter Guard-Modus Nur loggen, Externe Calls blockieren oder Auf Sandbox-Ziele umleiten. Nur loggen blockiert nichts. Erlaubte Hosts werden in jedem Modus unverändert angesprochen. Ein Outbound-Muster wie *.internal.test erlaubt Subdomains, jedoch nicht die Basisdomain. Ohne eigene Host-Liste gelten localhost, 127.0.0.1 und ::1.
9. Sandbox-Zuordnungen: Hinterlege in der Redirect-Map je Zeile eine Zuordnung wie live.example.test => https://sandbox.example.test. Diese Beispieldomains müssen durch deine Ziele ersetzt werden. Bei Host-Zuordnungen bleiben Request-Pfad und Query erhalten; ein Zielpfad wird dabei ersetzt. Bei URL-Zuordnungen wie https://live.example.test/api => https://sandbox.example.test/mock wird der passende Pfadrest an /mock angehängt. Quellen müssen an Pfadgrenzen passen. Externe Ziele benötigen HTTPS; HTTP ist für Loopback-Ziele erlaubt. Nutze Sandbox-Zugangsdaten, da eine Umleitung nicht automatisch Credentials ersetzt.
10. Fehlende Zuordnungen: Lasse Ziele ohne Redirect-Mapping blockieren aktiv, wenn unbekannte Ziele im Umleitungsmodus nicht angesprochen werden sollen. Ist die Option aus, werden solche Aufrufe unverändert mit einem Log-Hinweis weitergegeben.
11. Payment Guard: Aktiviere Payment Guard aktivieren und wähle unter Erlaubte Zahlungsarten ausschließlich bewusst eingerichtete Testzahlungsarten. Der Guard prüft die aktuell gewählte Zahlungsart und blockiert bei fehlender Freigabe die Bestellabgabe. Eine leere Auswahl blockiert alle Zahlungsarten. Er stellt Anbieter nicht auf Sandbox um und versteckt die Zahlungsarten nicht.
12. Audit-Log: Öffne Einstellungen > Erweiterungen > SafeStage Audit-Logs. Suche nach Testereignissen und nutze die Filter Kategorie und Entscheidung. Öffne einen Eintrag für Ziele und Metadaten. Das Recht system_config:read ist erforderlich, auch für den Administration-Banner. App-Logs setzen einen Shopware-Kontext voraus. Die täglichen Bereinigungsaufgaben löschen Einträge älter als 180 Tage, sofern Shopware Scheduled Tasks und Queue-Verarbeitung laufen.
13. Funktionskontrolle: Prüfe eine nicht freigegebene Mail, eine freigegebene Adresse, die gewählten App-Ziele und die Bestellabgabe mit einer nicht freigegebenen Zahlungsart. Kontrolliere Banner, Header, Meta-Tag und /robots.txt am betroffenen Host. Leere nach Änderungen den Shopware-Cache und baue ihn neu auf. Prüfe die Antworten anschließend erneut und berücksichtige vorhandene Proxy-Caches.

CLI-Kontrolle

php bin/console lunova:safe-stage:status zeigt den Status. Für maschinenlesbare Ausgabe verwende php bin/console lunova:safe-stage:status --json. Ein Verkaufskanal wird mit --sales-channel-id=DEINE_ID gewählt. Der Alias lautet lunova:testmode:status.

php bin/console lunova:safe-stage:robots gibt einen robots.txt-Block zur Vorschau aus und schreibt keine Datei. Bei inaktivem Schutz wird trotzdem der Block mit einer Warnung angezeigt. Prüfe deshalb zusätzlich die echte URL /robots.txt. Der Alias lautet lunova:testmode:robots.