🛡️ Protezione dei moduli e controllo degli accessi

I moduli propform sono accessibili pubblicamente per impostazione predefinita — il che è utile per richieste, feedback dei clienti e generazione di lead. Tuttavia, alcuni moduli dovrebbero poter essere aperti o inviati solo a determinate condizioni. Ecco i meccanismi di protezione disponibili.

Contenuto

• Honeypot e CSRF (attivi automaticamente)
• Whitelist IP
• Protezione con password (schermata di immissione)
• Chiave del modulo tramite parametro URL
• Data di scadenza
• Valori consentiti come anti-submit trick
• Filtro per modulo (limitazione dei record)
• Requisito UUID per la chiamata al modulo
• Confronto: quale protezione per cosa?

Honeypot & CSRF (attivi automaticamente)

Ogni modulo propform dispone di una protezione anti-bot integrata — senza che tu debba configurare nulla:

• Campo honeypot: campo invisibile che le persone reali non vedono, ma che i bot compilano → operazione interrotta, IP registrato
• Token CSRF: token crittografato al momento della chiamata, verificato al momento dell'invio → i bot senza una chiamata regolare falliscono
• Firma del modulo + timestamp: impedisce gli attacchi di replay

Maggiori informazioni su Protezione antispam e difesa dai bot.

Whitelist IP

Se un modulo deve essere accessibile solo da determinati intervalli IP (ad es. modulo interno per i dipendenti solo dall'ufficio):

Configurazione:

1. Impostazioni del modulo → Altre impostazioni → scorrere fino in fondo
2. Spuntare "Lista bianca IP"
3. Inserire gli indirizzi IP separati da virgola (ad es. 192.168.1.10, 91.42.42.42)

Limiti: max. 2000 caratteri → sono possibili diverse centinaia di IP

Cosa succede: chi non è presente nella whitelist vedrà un messaggio di errore "Il tuo IP non è autorizzato ad accedere a questo modulo".

> 💡 Suggerimento: scopri il tuo IP tramite whatismyip.com o servizi simili. In caso di IP domestici dinamici, è preferibile pianificare un intervallo di IP o utilizzare una VPN.

---

Protezione con password (schermata di immissione)

Protegge l'accesso e l'invio del modulo con una password. All'apertura compare prima una schermata di immissione al posto del modulo: solo dopo aver inserito la password corretta il modulo viene visualizzato e può essere inviato.

Configurazione:

1. Impostazioni modulo → Altre impostazioni → "Protezione con password attiva"
2. Definire una password — può anche essere una macro onOffice (ad es. _plz, in modo che il visitatore debba inserire il CAP del proprio record)
3. Facoltativo: testo di aiuto sopra il campo della password e un messaggio di errore personalizzato

Come funziona:

• Il visitatore inserisce la password nella schermata — non compare nell'URL.
• Dopo l'inserimento corretto, il modulo rimane sbloccato per 2 ore, anche al ricaricamento della pagina.
• La protezione vale sia per l'accesso che per l'invio.

Casi d'uso:

• Modulo interno per i dipendenti senza accesso pubblico
• Accesso privato per singoli clienti a cui comunichi la password separatamente
• Semplice verifica dell'identità tramite macro (ad es. "Inserisci il tuo CAP")

> 💡 Differenza con la chiave del modulo (sotto): Con la protezione con password, il visitatore inserisce personalmente la password in una schermata. Con la chiave del modulo, il valore è direttamente nel link come ?key= — ideale per link predisposti automaticamente.

> ⚠️ Avviso di sicurezza: la password viene salvata in chiaro nel database. Adatta per una protezione leggera, non per dati altamente sensibili. Un'autenticazione utente+password vera e propria con dati di accesso configurabili per ogni account è in programma.

---

Chiave del modulo tramite parametro URL

A differenza della protezione con password (con schermata di immissione), la chiave del modulo è direttamente come valore nell'URL — senza schermata di immissione, ideale per link predisposti automaticamente. Il valore può essere un valore dinamico di macro — ad es. un campo del record onOffice che può essere impostato solo una volta (anti-doppio invio).

Configurazione:

1. Impostazioni modulo → Altre impostazioni → "Chiave del modulo richiesta"
2. Definire la chiave — può essere una macro, ad es. _reservierung_aufgerufen
3. Messaggio di errore opzionale ("Hai già inviato il modulo")

Chiamata:

https://formular.deine-domain.de/reservierung?key=ja

→ Il valore dopo key= deve corrispondere esattamente al valore della macro risolta.

Caso d'uso del flusso di lavoro di prenotazione:

• All'inizio il campo _reservierung_aufgerufen in onOffice è vuoto → il modulo non può essere richiamato
• Tramite le impostazioni imposti il campo su ja (ad es. quando il cliente arriva alla fase di prenotazione)
• Dopo l'invio puoi reimpostare il campo su nein → Il modulo è bloccato per la ripetizione

Data di scadenza

Un modulo deve essere accessibile solo fino a una determinata data. Aggiungi la data di scadenza come parametro URL al link del modulo e attiva nelle impostazioni del modulo → "Data di scadenza obbligatoria".

https://formular.deine-domain.de/bewerbung?exp=2030-12-31 23:59:59

Importante: sono necessari data + ora

Il parametro ?exp= richiede data E ora — se si inserisce solo la data, l'operazione fallirà con il messaggio "Data di scadenza non valida".

Corretto:

?exp=2030-12-31 23:59:59

Errato (errore):

?exp=2030-12-31

Data di scadenza dinamica tramite macro DateAdd

Nei modelli di posta di onOffice puoi calcolare dinamicamente la data di scadenza — ad es. "Il link è valido per 14 giorni a partire da oggi":

?exp=_calculate(DateAdd(now;14;days)) 23:59:59

Unità per DateAdd: days, weeks, months, years. L'ora va aggiunta alla fine come stringa fissa, poiché DateAdd fornisce solo la data.

Casi d'uso:

• Moduli di candidatura con data di scadenza
• Offerte a tempo limitato
• Codici promozionali con validità

Valori consentiti come trucco anti-invio

Una soluzione ingegnosa se vuoi vincolare l'invio del modulo a una condizione aggiuntiva — senza autenticazione separata:

Schema:

1. Aggiungi un campo di testo nel modulo (può essere invisibile o visibile all'utente come "inserimento codice")
2. Impostazioni campo → Altre impostazioni → Imposta "Valori consentiti" sul valore desiderato, ad es. passwort1234
3. Al momento dell'invio, propform verifica i valori consentiti: se il valore non è corretto → nessun invio

Casi d'uso:

• Codice anti-spam per moduli pubblici ("Inserisci il codice dalla nostra e-mail")
• Codice di accesso monouso che invii tramite un canale separato
• Protezione aggiuntiva a Honeypot/CSRF

> 💡 Differenza rispetto all'Honeypot: l'Honeypot blocca i campi compilati automaticamente. Qui il valore deve essere inserito manualmente.

Filtro per modulo (limitazione dei record)

Se un modulo può caricare o modificare record (ad es. modulo di modifica indirizzo o di modifica immobile), puoi limitare l'accesso a un filtro onOffice — fondamentale per i moduli pubblici.

Configurazione:

1. Crea un filtro in onOffice (ad es. "solo immobili attivi", "solo stato > 5", "solo regione di marketing X")
2. Nel modulo propform → Campi indirizzo/immobili → Impostazioni filtro → seleziona il filtro
3. Effetto: il modulo può caricare/modificare esclusivamente i record di questo filtro — tutto il resto viene rifiutato

Maggiori informazioni nella FAQ separata: Filtro per modulo.

> ⚠️ Aspetto di sicurezza nei moduli pubblici: senza filtro, un utente può accedere a qualsiasi record visibile all'utente API manipolando l'UUID nell'URL. Il filtro limita l'accesso all'area desiderata.

---

Requisito UUID per la chiamata del modulo

Impedisce che un modulo possa essere richiamato senza un UUID di record valido nell'URL. Importante per i moduli di modifica e download, che richiedono sempre un record specifico.

Configurazione:

1. Impostazioni modulo → Altre impostazioni → "Immobile e/o indirizzo richiesti per le chiamate al modulo"
2. Selezionare quale dei due UUID è richiesto (entrambi possibili)

Cosa succede senza UUID:

• Il modulo non viene visualizzato, ma viene visualizzato un messaggio di errore
• Impedisce la manomissione dell'URL: l'utente rimuove un UUID dall'URL → altrimenti verrebbe creato un record vuoto
• Impedisce la creazione accidentale di record vuoti se il collaboratore invia il link senza riferimento a un record

Casi d'uso:

• Moduli di download (vedi Campi di download) — senza UUID nessun record, senza record nessun file
• Moduli di modifica dalla maschera onOffice (acquisizione, consegna, prenotazione)
• Moduli di stato/statistica per i proprietari

> 💡 Suggerimento di combinazione: requisito UUID + filtro per modulo + controllo duplicati indirizzi danno vita a uno stack di sicurezza molto solido per i moduli di modifica pubblici.

---

Confronto: quale protezione per cosa?

Correlati

• 📖 Protezione antispam e difesa dai bot — Meccanismo honeypot/CSRF
• 📖 Filtro per modulo — Limitazione dei record in dettaglio
• 📖 Protezione dei dati e minimizzazione dei dati — cosa viene memorizzato