WebBlocks CMS offre un'unica pipeline di protezione locale per i moduli rivolti ai visitatori. I blocchi nativi Contact Form e Comments la utilizzano direttamente, mentre plugin come WebBlocks Forms risolvono lo stesso servizio dal container del CMS. I segnali seguono quindi un sito attraverso diversi tipi di modulo, anziché lasciare che ogni modulo si difenda in modo isolato.

La pipeline non effettua richieste di rete e non richiede CAPTCHA, chiavi API, daemon, servizi di fingerprinting del browser, estensioni PHP opzionali o prodotti di moderazione di terze parti. Utilizza il database dell'applicazione, la cache Laravel configurata e APP_KEY.

La protezione è deliberatamente organizzata su più livelli:

1. La convalida Laravel e la protezione CSRF rifiutano normalmente le richieste non valide o provenienti da altre origini.
2. Il renderer fornisce un'identità firmata del modulo, un timestamp e un honeypot generato.
3. Una prova non valida, un honeypot compilato o un invio effettuato prima del tempo minimo previsto per il modulo seguono il percorso generico di successo, senza archiviazione né consegna.
4. Agli invii validi viene assegnato un punteggio in base a segnali relativi a contenuto, tempistica, ripetizione, mittente, origine, prefisso di rete, modulo e reputazione appresa.
5. Il punteggio determina allow, quarantine o spam.
6. Il modulo proprietario memorizza il record per la revisione; solo allow può eseguire le azioni di consegna.

I visitatori non ricevono mai il punteggio, le motivazioni, l'esito della notifica o la conferma che una trappola li abbia riconosciuti. La risposta generica impedisce ai bot di utilizzare l'endpoint per perfezionare i propri payload.

inspect() restituisce score, valori reasons univoci, decision e il flag di compatibilità is_spam. Le soglie predefinite sono:

Per i Contact Messages, la quarantena e lo spam disattivano la notifica e-mail. Per WebBlocks Forms disattivano ogni azione, incluse la notifica aziendale, la risposta automatica, il webhook e l'integrazione opzionale con Campaigns. I commenti non vengono mai pubblicati automaticamente: quelli puliti e in quarantena restano in attesa, mentre una decisione di spam viene archiviata come spam.

I segnali sono additivi e il punteggio finale è limitato a 100. Diversi segnali deboli possono quindi mettere in quarantena una richiesta senza dipendere da un'unica fragile regola basata su parole chiave.

Gli indirizzi e-mail vengono rimossi prima di calcolare il fingerprint del contenuto; in questo modo la rotazione del mittente non nasconde un messaggio ripetuto e la modifica di un indirizzo non crea una nuova copia della campagna.

Ogni contatore e ricerca della reputazione è limitato al sito. L'attività su un sito ospitato non può aumentare il punteggio di un altro sito.

• Le chiavi di cache per IP esatto, mittente, contenuto, modulo e rete utilizzano un HMAC con chiave; i valori inviati non compaiono nelle chiavi di cache.
• Gli indirizzi IPv4 vengono ridotti a /24 e quelli IPv6 a /64 prima dell'HMAC del prefisso di rete. Ciò rileva gli host a rotazione senza memorizzare l'indirizzo né utilizzare la geolocalizzazione.
• Le soglie di rete sono più alte di quelle per l'IP esatto, così uffici, scuole, gateway degli operatori e altre reti condivise non vengono penalizzati troppo presto.
• Le righe di somiglianza contengono un HMAC esatto, un SimHash a 64 bit, contatori e timestamp, non il messaggio inviato.
• Le metriche giornaliere contengono soltanto sito, data, superficie e conteggi aggregati delle decisioni.

La tabella proprietaria degli invii può comunque memorizzare le informazioni necessarie al prodotto; per esempio, un Contact Message memorizza l'indirizzo fornito dal visitatore e i dettagli dell'origine. Tale record del prodotto è separato dalla reputazione e dalle metriche della protezione.

wbcms_submission_fingerprints conserva la reputazione locale e limitata al sito. Le corrispondenze esatte hanno l'effetto maggiore; i quasi duplicati utilizzano un confronto SimHash limitato a un massimo dei 200 fingerprint visualizzati più di recente nei 90 giorni precedenti.

Contrassegnare come spam un Contact Message o un invio di WebBlocks Forms registra un feedback spam. Ripristinare un elemento di spam o in quarantena allo stato Nuovo, Letto o Risposto registra un feedback ham e compensa i successivi falsi positivi. L'archiviazione ha una funzione organizzativa e non insegna nulla. Il feedback influisce soltanto sugli invii successivi e non riclassifica retroattivamente i record esistenti.

I plugin chiamano recordOutcome($siteId, $validatedAnswers, 'spam') oppure utilizzano ham per una correzione.

Ogni invio valutato incrementa una riga in wbcms_submission_daily_totals per il relativo sito, la data e la superficie. Contact Messages mostra il riepilogo progressivo per i siti a cui l'amministratore autenticato può accedere. WebBlocks Forms lo mostra per il sito selezionato.

• Controllati: tutti gli invii validi che hanno raggiunto la fase di valutazione;
• Consentiti: la consegna normale è stata autorizzata;
• In quarantena: archiviati per la revisione con consegna disattivata;
• Spam: archiviati come spam con consegna disattivata.

Le richieste scartate da una trappola o inviate troppo rapidamente non raggiungono mai la fase di valutazione, non vengono archiviate e non rientrano in questi totali. Il riepilogo costituisce un contesto operativo, non un conteggio dei visitatori né un rapporto di accuratezza. summary($siteIds, $days) restituisce zeri finché la tabella delle metriche non è installata, mantenendo sicure le schermate dei plugin durante un aggiornamento incompleto.

Tutte le impostazioni sono override facoltativi tramite variabili d'ambiente. I valori predefiniti sono prudenti.

Mantenere la soglia di quarantena al di sotto di quella dello spam, la prima soglia di ogni raffica al di sotto della seconda e le finestre su valori positivi. Dopo aver modificato i valori d'ambiente in un'installazione con configurazione memorizzata nella cache, eseguire php artisan optimize:clear.

SubmissionProof associa i propri valori sia alla superficie sia all'identità del modulo. I renderer inviano _form_stamp, _form_check_name e il campo vuoto restituito da fieldName($surface, $form). I valori mancanti, alterati, con data futura o appartenenti a un altro modulo determinano un rifiuto sicuro.

La prova non è un token monouso: le cache delle pagine intere e le CDN possono servire lo stesso modulo a più visitatori reali. Il suo scopo è associare il modulo, garantirne l'integrità, denominare l'honeypot e misurare il tempo trascorso, non impedire la riproduzione.

I plugin restano responsabili di convalida, autorizzazione, limitazione della frequenza, archiviazione, nomi degli stati e rendering. Un plugin compatibile deve:

1. eseguire il rendering della prova firmata e di un honeypot generato vuoto;
2. scartare silenziosamente le prove non valide, le trappole compilate e gli invii al di sotto del proprio minimo vincolante;
3. passare a inspect() soltanto le risposte convalidate;
4. utilizzare l'ID reale del sito e identità stabili per superficie e modulo;
5. salvare il punteggio e le motivazioni insieme all'invio;
6. eseguire le azioni soltanto quando la decisione è allow;
7. inviare a recordOutcome() le correzioni spam/ham apportate dagli operatori;
8. utilizzare summary() anziché interrogare direttamente le tabelle delle metriche del CMS.

Non copiare il sistema di valutazione in un plugin, non indebolire le soglie valide per l'intera installazione, non esporre ai visitatori i codici delle motivazioni e non trasmettere le risposte a un altro servizio. WebBlocks Forms è l'implementazione di riferimento.

• Esaminare regolarmente la quarantena e lo spam; il ciclo di apprendimento dipende da correzioni intenzionali degli stati.
• Contrassegnare le campagne reali come Spam. Utilizzare Archivia soltanto per l'archiviazione organizzativa, poiché non addestra la reputazione.
• Ripristinare i falsi positivi a uno stato legittimo del flusso di lavoro.
• Modificare le soglie soltanto dopo aver osservato il traffico del sito. Conteggi più bassi per mittente o rete possono danneggiare il traffico proveniente da uffici condivisi o eventi.
• Un aumento di Controllati senza e-mail nella casella di posta può essere normale quando la quarantena o lo spam disattivano la consegna. La notifica e lo stato editoriale restano separati.
• Eseguire un backup prima di modificare APP_KEY. La rotazione rende i fingerprint HMAC e le chiavi di cache attive esistenti non confrontabili con quelli nuovi finché l'influenza dei dati precedenti non si esaurisce.

• Moduli di contatto e messaggi
• Commenti e valutazioni
• Sicurezza
• Operazioni
• Sistema dei plugin