Contrib.social

Missing support to store secret_key (and site_key) outside of configuration (DB)

Open on Drupal.org →
Created on 24 April 2025, 5 months ago

Problem/Motivation

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.

Steps to reproduce

  1. Add the following to settings.local.php:
    $config['hcaptcha.settings']['site_key'] = 'SITE';
$config['hcaptcha.settings']['secret_key'] = 'SECRET';
  2. Open /admin/config/people/captcha/hcaptcha to see that neither "Site key" nor "Secret key" are populated.
  3. Also, open /admin/config/people/captcha/examples to see that hCaptcha still renders the Math fallback, due to the missing keys.

Proposed resolution

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.

User interface changes

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

✨ Feature request
Status

Active

Version

1.0

Component

User interface

Created by

brevilo

Live updates comments and jobs are added and updated live.
  • Security improvements

    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.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 5 months ago →
    🇮🇹Italy apaderno Brescia, 🇮🇹
  • Comment 4 months ago →
    brevilo
  • @brevilo opened merge request.
  • Comment 4 months ago →
    brevilo

    Added two minor improvements but the MR is otherwise now ready for review.

    Thanks

  • Comment 4 months ago →
    brevilo
  • Comment 4 months ago →
    brevilo

    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!

  • Status changed to Needs review 13 days ago
  • Comment 13 days ago →
    🇩🇪Germany guido_s Cologne

    It would be great if the module would support using the key → module which seems to be kind of the new standard. There you can choose if you want to save the key in the configuration, an environment variable or in a file.

  • Comment 13 days ago →
    brevilo

    It would be great if the module would support using the key module which seems to be kind of the new standard

    Hm, I'm not convinced. A "new standard" shouldn't be offered as yet another module on which this module would have to depend, IMHO. I'd rather stick to core features. Also...

    There you can choose if you want to save the key in the configuration, an environment variable or in a file.

    ... most of this is already possible, no? At least configuration and environment is already possible in core Drupal. I use the latter via settings.php in conjunction with .env. Works flawlessly.

    What hCaptcha lacks is supporting what's already possible with Drupal core. That's what my patch is doing.

    Anyhow, just my opinion. It's for the maintainers to decide - if there are any... effectively... Right now this module seems to be abandoned, unfortunately. I'd love to be proven wrong, though.

    Cheers

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024