Storing secrets in the configuration (DB) is usually considered a potential security issue. Thus it would be preferable to store secret_key (and site_key) elsewhere, e.g. settings.local.php (typically augmented by .env).
Unfortunately that's not possible right now because HCaptchaAdminSettingsForm extends ConfigFormBase and hcaptcha.settings is declared editable in its entirety. That in turn means overrides in settings.local.php are ignored.
settings.local.php:$config['hcaptcha.settings']['site_key'] = 'SITE';
$config['hcaptcha.settings']['secret_key'] = 'SECRET';
/admin/config/people/captcha/hcaptcha to see that neither "Site key" nor "Secret key" are populated.
/admin/config/people/captcha/examples to see that hCaptcha still renders the Math fallback, due to the missing keys.
As an admin I would like to be able to optionally override secret_key and site_key in settings.local.php in such a way that their values don't bleed into the configuration (DB). Ideally, an existing override would cause the corresponding field to render as read-only, while still showing the overridden value. Saving the admin form (for unrelated changes to other settings) must not save any overridden fields to avoid secrets leaking into the DB.
See above.
Please see the related issues for context. I know this is probably a core issue but looking at the history I doubt that the proposed solution above (which I consider the only solution to this general problem) is going to be implemented globally any time soon, so a local solution (a.k.a workaround) would be highly appreciated.
Thanks
Active
1.0
User interface
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Added two minor improvements but the MR is otherwise now ready for review.
Thanks
Hi everyone,
since I'm new to the Drupal development workflow, I'm wondering, what can I do to attract a maintainer to comment on this issue and, ideally, to review this MR? AFAIK, issue comments don't support mentions → and I can't see who's following this issue, so it doesn't seem straight-forward to address people. Any help would be appreciated.
Thanks!