Confirmed Preserving inactive extraCaptchaKeys

[zeeb0t]

Affected version

2.1+

This may be intentional/by design, so I am not necessarily reporting it as a conventional bug. But I think the current behaviour is a little more destructive than the UI implies.

At the moment, if an admin configures credentials for one CAPTCHA provider, then switches XenForo’s global CAPTCHA provider to another provider and saves, the previously configured provider’s values in extraCaptchaKeys are dropped.

For example:

1. Configure Turnstile site key / secret.
2. Switch CAPTCHA provider to hCaptcha or reCAPTCHA.
3. Save.
4. Switch back to Turnstile.
5. The previous Turnstile values are gone.

As far as I can tell, this is not a storage/schema limitation. XenForo already has extraCaptchaKeys as an array capable of holding multiple provider-specific values. The issue appears to be the ACP option form submission behaviour: inactive provider fields are disabled by the radio/dependent UI, disabled fields are not serialized/submitted, and the save then treats the omitted inactive provider keys as gone.

For normal XenForo “one global CAPTCHA provider” usage, this is understandable. But I do not think “admin changed the selected provider” necessarily means “admin intended to permanently clear the credentials for every other provider”. That is especially true because the credentials are hidden/inactive at the time, so the destructive effect is not obvious.

A small front-end mitigation demonstrates that XenForo otherwise works fine with retained multi-provider config:

(function(window, document) {
  'use strict';

  var EXTRA_KEYS_PREFIX = 'options[extraCaptchaKeys]';

  function preserveExtraCaptchaKeys(form) {
    if (!form || !form.querySelector) {
      return;
    }

    if (!form.querySelector('[name="options[captcha]"]')) {
      return;
    }

    var fields = form.querySelectorAll('input, select, textarea');

    for (var i = 0; i < fields.length; i++) {
      if (fields[i].name && fields[i].name.indexOf(EXTRA_KEYS_PREFIX) === 0) {
        fields[i].disabled = false;
      }
    }
  }

  document.addEventListener('submit', function(event) {
    preserveExtraCaptchaKeys(event.target);
  }, true);

  document.addEventListener('ajax-submit:before', function(event) {
    preserveExtraCaptchaKeys(event.detail && event.detail.form ? event.detail.form : event.target);
  }, true);
})(window, document);

That is not necessarily the exact fix I would expect XenForo core to use. A server-side preservation step may be cleaner: when saving the CAPTCHA option form, merge omitted inactive extraCaptchaKeys values from the existing option unless the selected provider’s fields were actually submitted blank.

But the front-end mitigation shows the core point: if inactive provider fields are submitted rather than disabled/omitted, XenForo can retain the configuration and the selected global CAPTCHA provider still works normally.

My suggestion would be to treat changing the selected CAPTCHA provider as “change the active provider”, not “delete all inactive provider credentials”. If an admin wants to clear a provider’s credentials, they can select that provider, clear the visible fields, and save.