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
| Formular | Mechanismus | Besonderheit |
|---|---|---|
| Kundenregistrierung | RegisterRouteDecorator dekoriert die Core-Route RegisterRoute |
Die Prüfung läuft vor dem Anlegen des Kontos, es entstehen keine Fake-Konten. Aktiv, wenn Hauptschalter und "Registrierungsformular schützen" an sind |
| Kontaktformular | Subscriber auf das Event contact_form.send |
Kein eigener Schalter, geschützt sobald der Hauptschalter an ist |
| Newsletter-Anmeldung | Subscriber auf NewsletterRegisterEvent |
Eigener Schalter "Newsletter-Formular schützen" |
Alle drei Formulare nutzen dieselbe Widget-Einbindung und denselben zentralen Prüfpfad (SpamProtectionFacade), siehe Technische Details.
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. Fehltparent(), 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 (Grundaltcha_missingim Log).
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.
| Funktion | Rückgabe | Beschreibung |
|---|---|---|
altcha_enabled(salesChannelId) |
bool |
ALTCHA aktiv (Hauptschalter und Widget-Schalter) |
honeypot_enabled(salesChannelId) |
bool |
Honeypot aktiv (Hauptschalter und Honeypot-Schalter) |
honeypot_field(salesChannelId) |
string (HTML) |
Gibt das versteckte Honeypot-Feld aus |
form_token_field(salesChannelId) |
string (HTML) |
Gibt das signierte Token-Feld für die Mindest-Ausfüllzeit aus, leer bei Mindestzeit 0 |
newsletter_protection_enabled(salesChannelId) |
bool |
Newsletter-Schutz aktiv |
registration_protection_enabled(salesChannelId) |
bool |
Registrierungsschutz aktiv |
altcha_asset_version() |
string |
Versions-String für die Skript-URLs |
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.
| Ablehnungsgrund | Anzeige |
|---|---|
disposable_email (Wegwerf-E-Mail) |
Fehlermeldung am E-Mail-Feld über Shopwares Formularvalidierung, Snippet error.MMD_ALTCHA__DISPOSABLE_EMAIL |
| alle anderen Gründe (Honeypot, zu schnell, Gibberish, Inhaltsvalidierung, ALTCHA, Rate Limit) | Das Plugin wirft eine SpamDetectedException (HTTP 403, Fehlercode MMD_ALTCHA__SPAM_DETECTED). Shopware zeigt dafür seine allgemeine Fehlerseite, nicht eine Meldung am Feld |
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.