Changelog — PrestaWard Captcha

This changelog summarises, version by version, the impact on shops and e-commerce teams.

0.2.7

• New: local mode per form. The newsletter, contact form and availability notifications can be protected using local checks alone (signed timestamp, trap field, minimum submission time of 4 seconds and submission limit), without loading any third-party scripts or requiring keys. Each form retains its mode (Disabled, Observation or Protection) and only switches to Protection after passing the self-test in Observation mode. It is less secure against targeted bots than a provider and is never offered for access, registration, orders, password recovery, Back Office or comments. The statistics show how many submissions from each form were checked locally. A page served from a full cache for more than six hours may reject the submission; reloading the page resolves this.
• New: blocked email domains. A list that you create (one rule per line, either an exact domain or a wildcard for its subdomains, up to 100 rules) is applied to customer registration, including during the checkout process, and to the newsletter. A check is carried out before querying the provider, and any matching email is rejected with a neutral message that does not reveal the list. In ‘Observation’ mode, only what would have been rejected is logged. Neither the email nor its domain is stored: only a counter and an event containing no personal data for each rejection.
• New: minimum reCAPTCHA v3 score per form. If you leave this blank, the global score is used, so nothing changes until you set a value. An invalid value reverts to the global score.
• New: theme (light, dark or automatic) and size (normal or compact) for the reCAPTCHA v2 and Cloudflare Turnstile widgets, including when accessing the Back Office. The default settings retain the current appearance; reCAPTCHA v3 and invisible reCAPTCHA v2 do not display a widget. In reCAPTCHA, ‘automatic’ follows the visitor’s colour scheme.
• Access to the Back Office uses the same local fallback as customer forms, but only whilst the provider is unavailable and the server confirms this. A provider that has responded with ‘verification failed’ is still rejected as usual. Each instance of use is logged as ‘fallback used’; a switch per shop disables it, and the operator’s temporary pause remains in place. The login screen never becomes locked: the script reports the failure to the server and then submits the form regardless. During an outage, this login method is more vulnerable to a targeted bot; it is advisable to maintain PrestaWard Authenticator as a second line of defence. The integration failure safeguard still does not affect the Back Office.
• The dashboard is divided into tabs (Summary, Surfaces, Provider, and Statistics and Log) and only calculates data for the currently open tab. The Summary tab displays the status of each supplier, successful and failed checks from the last 24 hours, the active status of each form and, at most, one alert line linking to the tab where the issue is resolved. Each tab has its own Save button and saves only the settings it displays. The GO ON Agency support panel has its own tab, ‘Support’, which is always the last one, and the Integrity status appears at the very end of all the tabs.
• The ‘Interfaces’ tab has been redesigned: the forms table is now grouped; the selector no longer cuts off its text (it previously displayed ‘Desa’); and the ‘Save’ button is positioned outside the temporary pause card, without overlapping it. The theme and size of the widget can be adjusted in a section of this tab.
• Corrects the warning ‘forms activated without passing their test’: this used to appear even when all six forms were disabled. It now only counts forms that are not in ‘Disabled’ mode.
• In new installations, email alerts for incidents are disabled until you specify an email address, so the settings can be saved straight away. Installations that are updated retain their settings.
• Support emails (both new and reopened) display your shop’s logo in the header (with the shop name as alternative text) and a standard footer featuring the GO ON Agency logo and the signature ‘PrestaWard by GO ON Agency’, without any links or contact details. The footer logo is a file from the module itself, served from your shop.
• Fixes an issue where the body of the ticket email displayed internal codes (for example, ‘configuration_test’ or ‘opened’): it now indicates the form, the cause and the status with text translated into all nine languages.
• Fixes an issue where a failed call to the provider would cause a Front Office form to become unresponsive; calls to the provider from the shop script are now protected in the same way as those for accessing the Back Office.
• Unified design of the dashboard across the four PrestaWard modules: section headers, form cards with neutral borders and standard collapsible blocks, statistics displayed on a single line, and a larger GO ON Agency logo in the header. The main button is now a solid brand colour, without a gradient.
• Fixes an issue where, in PrestaShop 9, the admin theme displayed tabs with underlines as links and section titles in capital letters. The common styles override this only within the PrestaWard panel, so PrestaShop 1.7 and 8 look the same as before.
• Fixes an issue where, in PrestaShop 1.7, the module’s stylesheet was ignored when registered with the version number in the URL. The file is now checked and registered without parameters, so that the new styling appears in versions 1.7, 8 and 9.
• Fixes an issue where, in PrestaShop 9, synchronisation with Integrity would check the security token using a method that PrestaShop 9 does not use, which could result in it being rejected. It is now validated using the PrestaShop 9 service; in PrestaShop 1.7 and 8, the check remains the same.
• When the connection to Integrity cannot be updated at that moment, the panel displays a single message: the saved connection remains valid and will be retried automatically. The labels on all tabs have been translated into all nine languages.
• Local mode has its own submission limit (from 1 to 50 every 10 minutes). The update copies the current limit from the backup, so nothing changes after updating, and modifying one of the two limits no longer affects the other.
• Fixes an issue where, in PrestaShop 9, a rejected CAPTCHA (for example, due to an invalid site key in ‘Protection’) would only display PrestaShop’s generic message regarding the employee username or password. The module now displays its own message in all versions; PrestaShop 9 continues to append its generic line afterwards.
• Fixes an issue where the connection with Integrity would degrade in the ‘all shops’ context of the Back Office or when a shop other than the first one served the registration test. The installation ID is now read as a single unit from the global scope (or from the shop where it is stored) in any context; the update passes an ID stored in a shop to the global scope without regenerating it, and if it cannot be read, Integrity’s status is left as it was.
• The product header once again displays the GO ON Agency logo and the tagline ‘PrestaWard by GO ON Agency’, without any links.
• As long as you use a provider, your token is still required in exactly the same way as before. The detected surfaces, saved settings and the contract with the Integrity API remain unchanged, and the new ways of rejecting or verifying a form (local mode and blocked domains) are disabled by default. The update does not modify any tables: it simply adds new settings with values that preserve the current behaviour.

0.2.6

• Each form has its own mode in each shop (Disabled, Observation or Protection), rather than a single shop-wide mode plus toggles. This lets you protect access to the Back Office and only observe the contact form. A form only switches to Protection after passing the self-test in Observation, and the update preserves the current behaviour of each shop.
• Protection against provider downtime (customer forms in Protection mode): if the server confirms that reCAPTCHA or Turnstile cannot be used, the form is accepted only if it includes a signed timestamp, an empty invisible trap field, a few seconds having elapsed since the page loaded, and a normal submission rate. Every use is recorded in the statistics. This feature is enabled by default, can be disabled per shop, and the Back Office never uses it.
• Change to note: with this Protection enabled, an open circuit breaker no longer allows all shipments through, but instead applies these same local checks. Disable it to retain the previous behaviour.
• Server-side pre-filter (Protection mode): blocks obvious bots before contacting the provider, based solely on positive tests (trap field filled in, falsified timestamp, submissions faster than a human could type, or more than 30 submissions per form and visitor every 10 minutes). This can be disabled per shop.
• The new checks do not store any identifiable data: visitors are grouped into an anonymous pool with a key that changes every day, recorded only in a counter that is cleared after two days.
• New statistics panel: permitted and blocked submissions by form and day (7, 14 or 30 days), trend compared to the previous period, activations of Protection against provider downtime, requests rejected before reaching the provider, an indicator of possible false positives and, under Observation, the submissions that would have been blocked. It does not contain addresses or emails.
• Custom forms: a form that is not automatically recognised (one-page checkout, theme forms) can be assigned per shop to a protected surface using a CSS selector (up to ten). The dashboard warns that Protection is only effective if the form submits its data to a page that the module verifies.
• Integration Failure Guard (customer forms in Protection mode): if a form stops submitting the token to the server whilst the provider is operational (due to a theme update, custom JavaScript or the page cache), that form is automatically placed in a temporary Observation status and you receive a support ticket and an email. It returns to Protection after 15 minutes without the issue and three verified tokens. Access to the Back Office is never affected and obvious bots continue to be rejected.
• The update creates a small counter table and new settings with safe values, whilst retaining existing settings and events.
• The support and diagnostics panel is positioned just before the Integrity section, as in all other PrestaWard modules, and in the ‘all shops’ context it no longer disappears: it indicates that a shop must be selected.
• Synchronise with Integrity every time you open the dashboard, using a background request that never slows down the page, and no more than once per minute per shop.

0.2.5

• Fixes the Back Office login service in PrestaShop 1.7. In PrestaShop 9, the fix is limited to the Back Office login form and does not affect the administration API.
• Stops retrying registration with Integrity when the shop’s registration key changes, and displays a clear warning.
• Renews the signed Integrity policy before it expires and keeps the current policy if a renewal fails.
• Corrects the included policy key so that it works in PHP 7.1 and 7.2.
• Adds the GO ON Agency support panel in nine languages, with a downloadable diagnostic report that does not include customer data and is not sent automatically. It can only be downloaded by an employee with editing permissions who has selected a shop.
• The retention period for technical logs is now strictly enforced (30 days by default, configurable per shop): until now, they were stored indefinitely. Each shop deletes expired logs daily, and incidents are not affected.
• Declares compatibility from PrestaShop 1.7.7.0, the oldest version tested.

0.2.4

• Corrects the submission of the admin login via Turnstile after solving the CAPTCHA, whilst retaining the button that initiated the submission.
• Fixes the registration test in PrestaShop 9 and improves Integrity’s diagnostics and retry mechanism.

0.2.3

• Unreleased version, superseded by 0.2.4.

0.2.2

• Prevents other JavaScript handlers in the theme from initiating submission whilst the CAPTCHA is still pending.
• Eliminates endless loading states and requests made before a valid token is available.
• Displays the CAPTCHA when opening login or registration forms that were hidden when the page loaded.

0.2.1

• Restores the visible CAPTCHA before the first login attempt in the Front Office and Back Office.
• Prevents the cache from displaying an old or incorrect CAPTCHA after updating the module.
• Replaces the pop-up with an accessible, visible and mobile-friendly warning.
• It displays Back Office errors on the login screen as a single error message, without any blank pages.

0.2.0

• Adds Cloudflare Turnstile with encrypted credentials and independent selection by surface.
• Links each token to its protected action and renews the challenge on repeated submissions.
• Improves the detection of login, registration, password recovery, checkout, newsletter and notification forms.
• It incorporates a temporary, limited and audited operational pause, without weakening Integrity’s signed policy.
• Updates the dashboard, its responsive design and the translations for the nine languages.
• Enhances the fail-closed persistence of the latest verified Integrity policy.

0.1.2

• Distinguishes automated bursts from operational faults and prevents duplicate alerts.
• Automatically closes automated traffic incidents after a period of inactivity.

0.1.1

• Availability checks by surface before Protection can be activated.
• Operational status, incident history, filters, pagination and clean-up.
• Limited health telemetry and integration with Integrity’s heartbeat.

0.1.0

• First public release candidate.
• Protection set separately per surface and per shop.
• Integration with reCAPTCHA v2 and v3.
• Enrolment, signed policy and PrestaWard Integrity heartbeat.
• Checking for updates and the standard visual experience across the ecosystem.
• Multi-version compatibility and a complete catalogue in nine languages.