When editing the field settings, the chosen algorithms don't persist across saves, and the keys entered aren't validated against this list. So there are really two problems here, not saving config, and validations not applying.

Steps to reproduce:

  1. Add an SSH Key field to an entity.
  2. Choose some algorithms in the field settings.
  3. Save field settings.
  4. Edit the field settings again.
  5. Notice that all of the boxes are unchecked, even though you previously checked some.
  6. Have a user save a key for an unchecked algorithm.
  7. Notice that it's accepted, without a form validation failure.

Remaining tasks:

  1. Get the field config saving properly, and
  2. actually validate the form field against the chosen algorithms.
CommentFileSizeAuthor
Screenshot from 2026-03-17 22-18-40.png4.8 KBcolan

Comments

colan created an issue. See original summary.

colan’s picture

Okay, looks like it's saving, just not showing up on the form.

  • 3e0987c3 committed on 4.x
    Refs #3579902: Add a temporary algorithm allow list until we fetch from...

  • 0d5f2720 committed on 4.x
    Refs #3579902: Show users more precise errors on key validation.
    

  • colan committed 2716141b on 4.x
    Issue #3579902 by colan: Fix SshKeyConstraint to accept the factory's...

  • colan committed 49552bdf on 4.x
    Issue #3579902 by colan: Honor field-settings algorithm allowlist during...

  • colan committed ca591c8c on 4.x
    Issue #3579902 by colan: Restore saved algorithm checkboxes in field...
colan’s picture

Version: 4.0.0-alpha3 » 4.x-dev
Status: Active » Fixed

Both bugs stemmed from related shape/typing mismatches. The settings form rendered with no boxes checked even after a save because #default_value was passing the stored {algorithm: bool} mapping straight to a checkboxes element, which expects an indexed list of selected option keys. The validator's "any algorithm allowed" symptom traced back to the hardcoded fallback list introduced in 3e0987c3, which short-circuited the per-field $constraint->algorithm data that SshKeyItem::getConstraints() was already passing in.

Commit ca591c8 fixes the form by converting the mapping with array_keys(array_filter($settings['algorithm'])) before assigning to #default_value. Commit 49552bd fixes the validator the same way — reading $constraint->algorithm directly via array_keys(array_filter(...)) and using strict in_array so a checkbox label like 'ssh-rsa' doesn't loose-compare equal to TRUE. That second commit, however, exposed a third defect: Drupal's
ConstraintFactory::createInstance() instantiates constraints by passing a single positional options array (new SshKeyConstraint(['algorithm' => [...]])), but the previous constructor's first positional parameter was $algorithm, so the entire options array landed in $this->algorithm — double-wrapped. The existing tests didn't catch this because they construct with PHP named arguments, which bypass the factory path. Commit 2716141 fixes the constructor by routing $options through parent::__construct() so Symfony's property mapping does the right thing for both calling conventions.

The test suite gains two regression cases: testValidateAlgorithmDisabledByFieldSettings confirms a module-supported algorithm (e.g. ssh-dss) is rejected once the field setting excludes it, and testConstructorAcceptsOptionsArray locks in the singly-wrapped result for both factory-style and named-arg construction.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.