Forms: spam protection and privacy

The options live in Webal Blocks, Options, Forms tab. They apply to every Webal Blocks form and sign-up box.

How a form protects itself

Every form hides a field that only robots fill in, carries a signed time stamp (a form sent in less than a few seconds is refused; there is never a limit on taking longer), checks a security token, and limits how often one visitor can send it. A form can also ask for a captcha. A form that is assigned to no pages (Menu Assignment set to "No pages") does not accept messages: to switch a form off, unpublish it or choose "No pages".

For any form on a public page, choose the powcaptcha captcha in the module. It is part of Joomla 6.1 and later, it contacts no one outside your site, and it stops robots far better than the limits alone. Other captchas (reCAPTCHA, hCaptcha and so on) load a script from another company before the visitor agrees to anything: that is your choice, and it belongs in your cookie notice.

The limits

An IPv6 visitor is counted by their first 64 bits (one home or business line), and an IPv4 visitor on a dual-stack server as plain IPv4.

Behind a proxy, CDN or load balancer

Joomla sees the proxy's address unless Behind load balancer is switched on in Global Configuration. Switch it on only if your proxy replaces the X-Forwarded-For header with the real visitor address. A proxy that only adds to the header lets a visitor write any address they like, and the per-visitor limit then does nothing (the per-form ceiling and the captcha still do). Switched off behind a proxy, every visitor shares one address and one limit.

What is kept

• The limit table holds, for each visitor and form, a scrambled code made from the visitor's network and your site's secret key (not the address), a count and two times. Someone who also holds the secret key could work the code back for an IPv4 address, so treat the rows as personal data. They are deleted when the time window ends.
• A message that failed a check is shown again to the visitor once (what they typed and which fields to fix). That text is held in the visitor's session, which Joomla keeps in its session table, until it is shown once or the session ends.
• Nothing a visitor typed is stored by Webal Blocks, attached or logged. The error log (com_wblblocks_submit.php) holds the kind of error and the form's number, never an address or text. If Global Configuration has Log Almost Everything on, Joomla itself also writes visitor addresses to its own everything.php, in its own format; Webal Blocks cannot change that.
• Pages with a form and the page cache. A page that shows a Webal form (the Form module or the Webal contact page layout) is never kept by Joomla's System - Page Cache plugin: it carries the visitor's own security token and, after a failed send, what they typed. Other pages are cached as before. (The form's script asks for a fresh token just before it sends in any case.)

The Webal Form module

The Webal Form module (up to 20 boxes, see its own page) is built on this core, so every limit and protection above applies to it. Three things are specific to it:

• Nothing is stored. The message goes out as one plain-text email to the addresses typed in the module (at most three). The visitor's address is never used as the sender: it is only the Reply-To, and only when it is a plain valid address.
• The module is never cached, whatever its Caching setting says (it is created with Caching set to No caching), because each page carries the visitor's own security token and the moment the page was made. Never put a form inside a module that Joomla caches (a Modal, Offcanvas, Tabs or Accordion with Caching on, a Custom module with {loadmoduleid} and Caching on, or another extension's container): a Webal host leaves the form out and tells a Super User, and in any other host the form is printed without anything a visitor typed and the host is not kept for that visit. Open the host and choose No caching, or do not put the form in it.
• Without JavaScript the form still works: it posts, Joomla sends the visitor back to the same page, and the form comes back with what they typed, a list of the problems and Joomla's own message. With JavaScript the same checks run on the server, and the answer is shown in place.

The Webal Newsletter module

The Webal Newsletter module (see its own page) signs visitors up to a Mailchimp audience and is built on the same core, so every limit and protection above applies to it. Mailchimp is the only service supported.

• The API key is saved in Webal Blocks, Options, Newsletter, by a Super User only. It is the one secret Webal Blocks keeps. The key is stored encrypted (libsodium, key derived from the site secret), so the database, the cache files and Joomla's Web Services API show scrambled text only; if the site secret is changed, the saved key cannot be opened and a Super User is asked to type it again. The box is always empty: once saved, the key is never shown again, not even partly, and not after a refused save either. Leave the box empty to keep the key when you save other Options; tick Remove the saved key to delete it. Nobody who is not a Super User can see or change it, even by sending the form by hand. The key is read by one piece of code, goes to Mailchimp in the request's Authorization header and appears nowhere else: not in a page, an answer, a log or a cache.
• Where it calls. The website calls Mailchimp over a secure connection (the certificate is checked, redirects are not followed, a call that takes more than ten seconds is given up, proxy settings from the environment are ignored). Every sign-up answers after at least one and a half seconds, whatever the outcome. The address is built only from the short code at the end of the key (for example us21) and only when that code has the right shape.
• Nobody can learn who is subscribed. A new address, one already on your list, one waiting for confirmation, one that unsubscribed, one Mailchimp will never add again: the visitor reads the same sentence and the page answers in the same way. The only answer that differs is Mailchimp calling the address invalid, which is about what the visitor typed. An address that unsubscribed earlier (or was cleaned, archived or only a transactional contact) and signs up again is sent a new confirmation email (its status becomes pending), and the details of an existing subscriber are never changed by a stranger.
• What Mailchimp records. The address and name, and the time and internet address of the sign-up. Say so in your privacy policy. With double opt-in on (the default) Mailchimp sends a confirmation email and adds the person only after they click it. Webal Blocks stores nothing itself except the spam-limit code described above.
• A sign-up box with no saved key, or with no valid Audience ID, is not shown to visitors and a Super User is told why.