Markus Michalski FAQ

ALTCHA: Erweiterbarkeit und Kompatibilität

ALTCHA Spam-Schutz für Sylius - eigene Schutzziele per Service-Tag registrieren, Interfaces dekorieren und die Abwärtskompatibilitäts-Zusage nach Semantic Versioning

English Version

Zurück zur Übersicht

ALTCHA: Erweiterbarkeit und Kompatibilität

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

Eigene Schutzziele

Ein neues Schutzziel aus einem Plugin registrieren. Registriere am besten Mmd\SyliusAltchaPlugin\Target\ProtectionTarget direkt als Service, statt selbst ProtectionTargetInterface zu implementieren. Das Interface kann in einem Minor-Release neue Methoden bekommen, der Konstruktor von ProtectionTarget dagegen erhält am Ende höchstens optionale Parameter. Verwende benannte Argumente und einen Übersetzungs-Key als Label. Der Konstruktor hat die Parameter $code, $label, $formTypes, $routes, $events, $enabledByDefault und $requiresProof; nur $code und $label sind Pflicht:

services:
    App\Altcha\OrderFormTarget:
        class: Mmd\SyliusAltchaPlugin\Target\ProtectionTarget
        arguments:
            $code: order_form
            $label: app.altcha.target.order_form
            $events: ['app.order_form.pre_submit']
        tags: ['mmd_sylius_altcha.protection_target']

Erst der Tag bringt das Schutzziel in die Admin-Liste. Ein Service, der ProtectionTargetInterface implementiert, bekommt ihn nur dann automatisch, wenn Autoconfiguration aktiv ist.

Ein Schutzziel legt fest, wie es durchgesetzt wird: über einen Formulartyp, einen Routennamen oder ein ablehnbares Event deines Plugins. Das Event braucht getRequest(): Request und reject(?string $reason). Ein optionales getSource(): BackedEnum mit dem Wert registration oder admin nimmt diese Einstiegspunkte von der Prüfung aus. Codes mit dem Präfix custom_ sind für Formulare reserviert, die im Admin angelegt werden.

Das Widget muss im Template des Formulars platziert werden, bevor das Schutzziel angehakt wird, siehe Storefront-Integration.

Dekorieren statt ableiten

Erweitere das Verhalten, indem du die öffentlichen Interfaces dekorierst (SubmissionGuardInterface, RateLimiterInterface, ReplayGuardInterface, AltchaVerifierInterface, DisposableEmailGuardInterface, GibberishGuardInterface und weitere), statt von den Klassen zu erben.

Abwärtskompatibilität

Von Semantic Versioning abgedeckt sind:

Nicht abgedeckt sind die Konstruktoren aller Klassen außer dem von ProtectionTarget, geschützte Member jeder Klasse, sonstige öffentliche Methoden sowie jede Klasse und jedes Interface mit der Markierung @internal. Auch die Persistenzschicht fällt heraus: Die Interfaces ChannelSettingsRepositoryInterface, DynamicTargetSourceInterface und DisposableDomainOverrideRepositoryInterface tragen @internal, die Entities ChannelSettings und DisposableDomainOverride zählen als sonstige Klassen. Die mitgelieferte Wegwerf-Domain-Liste ist Inhalt, keine API: Pfad, Format und die enthaltenen Domains können sich jederzeit ändern, auch in einem Patch-Release.