English Version

Zurück zur Übersicht

ALTCHA Spam-Schutz: Storefront-Integration

Diese Dokumentation bezieht sich immer auf die aktuellste veröffentlichte Version.

Live Demo: Teste dieses und weitere Plugins live — ohne Installation, ohne Risiko: demo.markus-michalski.net

Geschützte Formulare

Alle drei Formulare nutzen dieselbe Widget-Einbindung und denselben zentralen Prüfpfad (SpamProtectionFacade), siehe Technische Details.

Wie das Widget eingebunden wird

Das Plugin erweitert die Standard-Templates von Shopware über sw_extends und ergänzt in den Captcha-Block des Formulars das Widget, das Honeypot-Feld und das Feld für den Formular-Token:

{% sw_extends '@Storefront/storefront/component/account/register.html.twig' %}

{% block component_account_register_captcha %}
    {{ parent() }}
    {% if registration_protection_enabled(context.salesChannel.id) %}
        {% if altcha_enabled(context.salesChannel.id) %}
            <script src="{{ asset('bundles/mmdaltchaintegration/altcha/altcha.min.js') }}?v={{ altcha_asset_version() }}" type="module"></script>
            <script src="{{ asset('bundles/mmdaltchaintegration/altcha/altcha-i18n-de.js') }}?v={{ altcha_asset_version() }}" type="module"></script>

            <altcha-widget challenge="/altcha/challenge" name="altcha"></altcha-widget>
        {% endif %}

        {% if honeypot_enabled(context.salesChannel.id) %}
            {{ honeypot_field(context.salesChannel.id)|raw }}
        {% endif %}

        {{ form_token_field(context.salesChannel.id)|raw }}
    {% endif %}
{% endblock %}

Betroffen sind drei Blöcke der Core-Templates: component_account_register_captcha (Registrierung), cms_form_contact_captcha (Kontakt) und cms_form_newsletter_captcha (Newsletter).

Eigenes Theme: Überschreibt dein Theme einen dieser Blöcke selbst, muss das Override {{ parent() }} aufrufen, damit Widget, Honeypot-Feld und Token-Feld weiter ausgegeben werden. Fehlt parent(), läuft die Absendung serverseitig trotzdem durch die Prüfkette, nur fehlt das Widget im Browser. Solange ALTCHA aktiv ist, lehnt der Shop sie dann ab (Grund altcha_missing im Log).

graph LR
    A["Core-Template"] --> B["Plugin-Template per sw_extends"]
    B --> C{"Theme überschreibt denselben Block?"}
    C -->|"Nein"| D["Widget, Honeypot und Token werden ausgegeben"]
    C -->|"Ja, mit parent()"| D
    C -->|"Ja, ohne parent()"| E["Schutz-Markup fehlt, Absendung wird abgelehnt"]

Widget-Assets und Sprache

Das Widget kommt aus dem Plugin, nicht von einem CDN:

bundles/mmdaltchaintegration/altcha/altcha.min.js
bundles/mmdaltchaintegration/altcha/altcha-i18n-de.js

Die Skript-URLs tragen eine Versions-Query (?v=...), damit Browser nach einem Update nicht das alte Widget aus dem Cache laden. Der Challenge-Pfad /altcha/challenge ist im Template fest eingetragen.

Für die Widget-Texte wählt das Widget die Sprache in dieser Reihenfolge: zuerst eine konfigurierte Sprache, dann die Dokumentsprache, danach die Browsersprachen als Rückfall. Das Plugin registriert nur ein deutsches Sprachpaket. Deshalb kann das Widget auch auf einer englischen Seite deutsche Texte zeigen, wenn der Browser des Besuchers auf Deutsch eingestellt ist. Für andere Sprachen gelten die Standardtexte des Widgets.

Die Fehlermeldung unter der Checkbox ist das Shopware-Snippet mmdAltcha.widget.error ("Überprüfung fehlgeschlagen" bzw. "Verification failed") und lässt sich unter Einstellungen > Shop > Snippets anpassen.

Twig-Funktionen

Eigene Formulare absichern

Das Widget und die Felder setzt du in einem eigenen Formular mit denselben Bausteinen ein:

{% if altcha_enabled(context.salesChannel.id) %}
    <script src="{{ asset('bundles/mmdaltchaintegration/altcha/altcha.min.js') }}?v={{ altcha_asset_version() }}" type="module"></script>
    <altcha-widget challenge="/altcha/challenge" name="altcha"></altcha-widget>
{% endif %}

{% if honeypot_enabled(context.salesChannel.id) %}
    {{ honeypot_field(context.salesChannel.id)|raw }}
{% endif %}

{{ form_token_field(context.salesChannel.id)|raw }}

Die serverseitige Prüfung koppelt das Plugin nicht automatisch an neue Formulare. Du rufst SpamProtectionFacade::validate() selbst auf, etwa in einem Controller oder Event-Subscriber, mit einem SpamCheckRequest (IP, Payload aus dem Feld altcha, Formulardaten, Kontext, Verkaufskanal, Aktion). Ein stabiler Erweiterungsvertrag ist das nicht: Die Klassen sind interne Plugin-Klassen.

Wie eine Ablehnung angezeigt wird

Nur die Wegwerf-E-Mail ist für den Besucher behebbar, deshalb bekommt sie eine konkrete Meldung am Feld. Alle anderen Gründe bleiben vage, damit ein Bot nicht erfährt, welche Schicht ihn gestoppt hat. Den tatsächlichen Grund (reason) findest du im Shopware-Log, siehe Technische Details.