🛡️ Form Protection & Access Control

propform forms are publicly accessible by default — which makes sense for enquiries, customer feedback and lead generation. However, some forms should only be opened or submitted under certain conditions. Here are the available protection mechanisms.

Contents

• Honeypot & CSRF (automatically enabled)
• IP Whitelist
• Form Password
• Form Key via URL Parameter
• Expiry Date
• Allowed values as anti-submit trick
• Filter per form (record limit)
• UUID requirement for form submission
• Comparison: Which protection for what?

---

Honeypot & CSRF (automatically active)

Every propform form has built-in bot protection — without you having to configure anything:

• Honeypot field: an invisible field that real people cannot see, but bots fill in → process aborted, IP logged
• CSRF token: encrypted token generated on request, verified on submission → bots without a valid request fail
• Form signature + timestamp: prevents replay attacks

Find out more under Spam Protection & Bot Defence.

## IP Whitelist

If a form is to be accessible only from specific IP ranges (e.g. an internal staff form accessible only from the office):

Setup:

1. Form settings → Advanced settings → scroll right to the bottom
2. Tick the box for “IP whitelist”
3. Enter IP addresses separated by commas (e.g. 192.168.1.10, 91.42.42.42)

Limits: max. 2000 characters → several hundred IPs possible

What happens: Anyone not on the whitelist will see an error message stating “Your IP is not authorised to access this form”.

> 💡 Tip: Find out your own IP via whatismyip.com or similar services. For dynamic home IPs, it is better to specify an IP range or use a VPN.

---

Form password

Protects access to the form. Without the correct password, the form will not be displayed at all.

Setup:

1. Form settings → Advanced settings
2. (Currently implemented as a hidden option — we will enable it on request. Drop us a quick line at hello@propform.io.)
3. Define password

Call:

https://formular.deine-domain.de/dein-formular?password=geheim123

Use cases:

• Internal staff form without public access
• Private test link for individual customers

> ⚠️ Security note: The password appears in plain text in the URL and is currently also stored unencrypted in the database. Suitable for light protection, not for highly sensitive data. Genuine user+password authentication with access details configurable per account is on the roadmap.

---

Form key via URL parameter

Unlike the form password, the form key checks a dynamic value — e.g. a field from the onOffice record that may only be set once (anti-double-submit).

Setup:

1. Form settings → Further settings → “Form key required”
2. Define key — can be a macro, e.g. _reservierung_aufgerufen
3. Optional error message (“You have already submitted the form”)

Call:

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

→ The value after key= must match the resolved macro value exactly.

Use case: Reservation workflow:

• Initially, field _reservierung_aufgerufen is empty in onOffice → The form cannot be called
• Via setup, you set the field to ja (e.g. when the customer reaches the reservation step)
• After submission, you can reset the field to nein → Form is locked to prevent repetition

## Expiry date

A form should only be accessible until a specific date. You append the expiry date as a URL parameter to your form link and enable “Expiry date required” in the form settings.

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

Important: Date + time required

The ?exp= parameter requires date AND time — using the date alone will result in an error: “Expiry date invalid”.

Correct:

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

Incorrect (fails):

?exp=2030-12-31

Dynamic expiry date using the DateAdd macro

In onOffice mail templates, you can calculate the expiry date dynamically — e.g. “Link valid for 14 days from today”:

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

Units for DateAdd: days, weeks, months, years. You append the time as a fixed string at the end, because DateAdd itself only provides the date.

Use cases:

• Application forms with a deadline
• Time-limited offers
• Promotional codes with validity dates

---

Allowed values as an anti-submit trick

A clever workaround if you want to link the submission of the form to an additional condition — without separate authentication:

Pattern:

1. Add a text field to the form (can be invisible, or visible to the user as a “code input”)
2. Field settings → Advanced settings → Set “Allowed values” to the desired value, e.g. passwort1234
3. When the form is submitted, propform checks the allowed values: if the value is incorrect → no submission

Use cases:

• Anti-spam code for public forms (“Enter the code from our email”)
• One-time passcode sent via a separate channel
• Additional protection alongside Honeypot/CSRF

> 💡 Difference from Honeypot: Honeypot blocks automatically filled fields. Here, the value must be entered manually.

---

Filter per form (record restriction)

If a form can load or edit records (e.g. address edit or property edit form), you can restrict access to an onOffice filter — critical for public forms.

Setup:

1. Create a filter in onOffice (e.g. ‘active properties only’, ‘status > 5 only’, ‘marketing region X only’)
2. In the propform form → Address/Property fields → Filter settings → select the filter
3. Effect: The form can only load/edit records from this filter — everything else is rejected

More on this in the separate FAQ: Filter per form.

> ⚠️ Security aspect for public forms: Without a filter, a user can access any records visible to the API user by manipulating the UUID in the URL. The filter restricts this to the desired range.

---

UUID requirement for form calls

Prevents a form from being called at all without a valid record UUID in the URL. Important for edit and download forms, which always require a specific record.

Setup:

1. Form settings → Further settings → “Property and/or address required for form calls”
2. Select which of the two UUIDs is required (both are possible)

What happens without a UUID:

• Form is not displayed; an error message appears instead
• Prevents URL tampering: if a user removes a UUID from the URL, an empty record would otherwise be created
• Prevents the accidental creation of empty records if an employee sends the link without a record reference

Use cases:

• Download forms (see Download fields) — no record without a UUID, no files without a record
• Editing forms from within the onOffice interface (acquisition, handover, reservation)
• Status/statistics forms for owners

> 💡 Combination tip: UUID requirement + filter per form + address duplicate check results in a very robust security stack for public editing forms.

---

Comparison: Which protection for what?

Related

• 📖 Spam protection & bot defence — Honeypot/CSRF mechanism
• 📖 Filters per form — Record restriction in detail
• 📖 Data protection & data minimisation — what is stored