🛡️ Protección de formularios y control de acceso

Los formularios de propform son accesibles públicamente por defecto, lo cual resulta útil para consultas, comentarios de clientes y generación de clientes potenciales. Sin embargo, algunos formularios deben poder abrirse o enviarse solo bajo determinadas condiciones. A continuación se detallan los mecanismos de protección disponibles.

Contenido

• Honeypot y CSRF (activado automáticamente)
• Lista blanca de IP
• Protección con contraseña (pantalla de entrada)
• Clave del formulario mediante parámetro de URL
• Fecha de caducidad
• Valores permitidos como medida anti-submit
• Filtro por formulario (limitación de registros)
• Requisito de UUID para la llamada al formulario
• Comparación: ¿qué protección para qué?

Honeypot y CSRF (activos automáticamente)

Cada formulario de propform cuenta con protección contra bots integrada, sin que tengas que configurar nada:

• Campo honeypot: campo invisible que las personas reales no ven, pero que los bots rellenan → proceso cancelado, IP registrada
• Token CSRF: token cifrado al acceder al formulario, verificado al enviarlo → los bots sin acceso regular fallan
• Firma del formulario + marca de tiempo: evita ataques de repetición

Más información en Protección contra spam y defensa contra bots.

## Lista blanca de IP

Si un formulario solo debe ser accesible desde determinados rangos de IP (por ejemplo, un formulario interno para empleados solo desde la oficina):

Configuración:

1. Ajustes del formulario → Ajustes adicionales → desplázate hasta el final
2. Marca la casilla «Lista blanca de IP»
3. Introduce las direcciones IP separadas por comas (p. ej., 192.168.1.10, 91.42.42.42)

Límites: máx. 2000 caracteres → es posible introducir varios cientos de direcciones IP

Qué ocurre: Quienes no figuren en la lista blanca verán el mensaje de error «Tu IP no está autorizada para acceder a este formulario».

> 💡 Consejo: Averigua tu propia IP a través de whatismyip.com o servicios similares. En el caso de IP domésticas dinámicas, es mejor planificar un rango de IP o utilizar una VPN.

## Protección con contraseña (pantalla de entrada)

Protege el acceso y el envío del formulario con una contraseña. Al abrirlo, aparece primero una pantalla de entrada en lugar del formulario; solo tras introducir la contraseña correcta se muestra el formulario y puede enviarse.

Configuración:

1. Ajustes del formulario → Ajustes adicionales → «Protección con contraseña activa»
2. Definir una contraseña — también puede ser una macro de onOffice (p. ej., _plz, para que el visitante tenga que introducir el código postal de su propio registro)
3. Opcional: texto de ayuda sobre el campo de contraseña y un mensaje de error propio

Cómo funciona:

• El visitante introduce la contraseña en la pantalla; no aparece en la URL.
• Tras introducirla correctamente, el formulario permanece desbloqueado durante 2 horas, incluso al recargar la página.
• La protección se aplica tanto al acceso como al envío.

Casos de uso:

• Formulario interno para empleados sin acceso público
• Acceso privado para clientes individuales a quienes comunicas la contraseña por separado
• Comprobación de identidad sencilla mediante macro (p. ej., «Introduce tu código postal»)

> 💡 Diferencia con la clave del formulario (abajo): Con la protección con contraseña, el visitante introduce él mismo la contraseña en una pantalla. Con la clave del formulario, el valor está directamente en el enlace como ?key=, ideal para enlaces preparados automáticamente.

> ⚠️ Aviso de seguridad: La contraseña se almacena sin cifrar en la base de datos. Adecuada para una protección básica, no para datos altamente confidenciales. Una auténtica autenticación de usuario y contraseña con datos de acceso configurables por cuenta está prevista en la hoja de ruta.

---

Clave de formulario mediante parámetros de URL

A diferencia de la protección con contraseña (con pantalla de entrada), la clave del formulario está directamente como valor en la URL, sin pantalla de entrada, ideal para enlaces preparados automáticamente. El valor puede ser un valor dinámico de macro, por ejemplo, un campo del registro de onOffice que solo se puede establecer una vez (anti-envío duplicado).

Configuración:

1. Ajustes del formulario → Ajustes adicionales → «Clave del formulario obligatoria»
2. Definir la clave — puede ser una macro, p. ej., _reservierung_aufgerufen
3. Mensaje de error opcional («Ya ha enviado el formulario»)

Llamada:

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

→ El valor detrás de key= debe coincidir exactamente con el valor de la macro resuelta.

Caso de uso: flujo de trabajo de reservas:

• Al principio, el campo _reservierung_aufgerufen está vacío en onOffice → No se puede llamar al formulario
• Mediante la configuración, estableces el campo en ja (por ejemplo, cuando el cliente llega al paso de reserva)
• Tras el envío, puedes volver a establecer el campo en nein → El formulario queda bloqueado para su repetición

---

Fecha de caducidad

Un formulario debe estar disponible solo hasta una fecha determinada. Añade la fecha de caducidad como parámetro de URL a tu enlace de formulario y activa en la configuración del formulario → «Fecha de caducidad obligatoria».

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

Importante: se necesita fecha + hora

El parámetro ?exp= necesita fecha Y hora; si solo se introduce la fecha, se producirá un error con el mensaje «Fecha de caducidad no válida».

Correcto:

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

Incorrecto (fallo):

?exp=2030-12-31

Fecha de caducidad dinámica mediante la macro DateAdd

En las plantillas de correo de onOffice puedes calcular la fecha de caducidad de forma dinámica — p. ej., «El enlace es válido durante 14 días a partir de hoy»:

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

Unidades para DateAdd: days, weeks, months, years. La hora se añade al final como una cadena fija, ya que DateAdd solo proporciona la fecha.

Casos de uso:

• Formularios de solicitud con fecha límite
• Ofertas por tiempo limitado
• Códigos promocionales con validez limitada

---

Valores permitidos como truco anti-envío

Una solución ingeniosa si quieres vincular el envío del formulario a una condición adicional, sin necesidad de autenticación por separado:

Patrón:

1. Añade un campo de texto al formulario (puede ser invisible o visible para el usuario como «Introducción de código»)
2. Configuración del campo → Configuración adicional → Establece «Valores permitidos» en el valor deseado, p. ej., passwort1234
3. Al enviar el formulario, propform comprueba los valores permitidos: si el valor no es correcto → no se envía el formulario

Casos de uso:

• Código antispam para formularios públicos («Introduce el código de nuestro correo electrónico»)
• Código de acceso único que envías por un canal independiente
• Protección adicional al honeypot/CSRF

> 💡 Diferencia con respecto al honeypot: el honeypot bloquea los campos rellenados automáticamente. Aquí, el valor debe introducirse manualmente.

---

Filtro por formulario (restricción de registros)

Si un formulario puede cargar o editar registros (por ejemplo, el formulario de edición de direcciones o de edición de inmuebles), puedes restringir el acceso a un filtro de onOffice, lo cual es fundamental en el caso de los formularios públicos.

Configuración:

1. Crea un filtro en onOffice (p. ej., «solo inmuebles activos», «solo estado > 5», «solo región de marketing X»)
2. En el formulario de propform → Campos de dirección/inmuebles → Configuración de filtro → selecciona el filtro
3. Efecto: el formulario puede cargar/editar exclusivamente registros de este filtro; todo lo demás se rechaza

Más información al respecto en la FAQ independiente: Filtro por formulario.

> ⚠️ Aspecto de seguridad en los formularios públicos: Sin filtro, un usuario puede acceder a cualquier registro que vea el usuario de la API mediante la manipulación del UUID en la URL. El filtro limita esto al ámbito deseado.

Requisito de UUID para la llamada al formulario

Impide que se pueda llamar a un formulario sin un UUID de registro válido en la URL. Importante en formularios de edición y descarga, que siempre necesitan un registro concreto.

Configuración:

1. Ajustes del formulario → Ajustes adicionales → «Se requiere propiedad y/o dirección para acceder al formulario»
2. Seleccionar cuál de los dos UUID se requiere (ambos son posibles)

Qué ocurre sin UUID:

• El formulario no se muestra; en su lugar, aparece un mensaje de error
• Evita la manipulación de la URL: si el usuario elimina un UUID de la URL, de lo contrario se crearía un registro vacío
• Evita la creación accidental de registros vacíos si el empleado envía el enlace sin referencia a un registro

Casos de uso:

• Formularios de descarga (véase Campos de descarga) — sin UUID no hay registro, sin registro no hay archivos
• Formularios de edición desde la máscara de onOffice (captación, traspaso, reserva)
• Formularios de estado/estadísticas para propietarios

> 💡 Consejo de combinación: el requisito de UUID + filtro por formulario + comprobación de duplicados de direcciones da como resultado una pila de seguridad muy sólida para los formularios de edición públicos.

---

Comparación: ¿qué protección para qué?

Relacionado

• 📖 Protección contra spam y defensa contra bots — Mecánica de honeypot/CSRF
• 📖 Filtro por formulario — Restricción de registros en detalle
• 📖 Protección de datos y minimización de datos — ¿qué se almacena?