Problem/Motivation

DefaultSelection::validateTargetBundles() converts an empty target bundle selection from [] to NULL, meaning that all bundles are referenceable.

For entity types with bundles, the configuration form however requires at least one target bundle to be selected. Neither [] nor NULL is accepted. As noted in #20, the conversion therefore cannot enable a successful form submission without a selected bundle.

As for the background requested in #9, the #required flag was introduced per #1953444: Make 'target bundles' required on the Entity reference instance settings form. Its purpose was to prevent site builders from overlooking the bundle selection, thereby selecting all bundles by default, even future ones.

Even worse, a semantic that turns [] (no bundles allowed) into NULL (all bundles allowed) is inherently problematic, whenever the last previously selected bundle happens to be deleted from the entity type, as described in #3031637-17: Entity reference: allow specifiying that every bundle is allowed.

For entity types with bundles, the form validator validateTargetBundles() should therefore be deprecated and subsequently removed. For bundleless entity types, the form should supply NULL directly.

This issue does aim to change the handler's default configuration, the bundle selection's #required flag, or the supported NULL/[] semantics.

Steps to reproduce

  1. Inspect DefaultSelection::buildConfigurationForm().
  2. For entity types with bundles, observe that target_bundles is #required.
  3. For bundleless entity types, observe that the form supplies [] through a value element.
  4. Observe that both cases register validateTargetBundles(), which converts [] to NULL.

Proposed resolution

  • Set the form element's value directly to NULL for bundleless entity types.
  • Remove the registration of validateTargetBundles().
  • Deprecate the public static method for backward compatibility.

Remaining tasks

Review.

User interface changes

None. Target bundle selection remains #required for entity types with bundles.

API changes

None. The public callback remains available, and programmatic configuration continues to support both NULL and [] for target_bundles.

Data model changes

None. The resulting saved configuration remains unchanged.

Original Report

For security reasons, we took the explicit design decision that if no target bundle is configured, we shouldn't fall back to allowing all bundles.

However, DefaultSelection::validateConfigurationForm() still contains:

    // If no checkboxes were checked for 'target_bundles', store NULL ("all
    // bundles are referenceable") rather than empty array ("no bundle is
    // referenceable" - typically happens when all referenceable bundles have
    // been deleted).
    if ($form_state->getValue(['settings', 'handler_settings', 'target_bundles']) === []) {
      $form_state->setValue(['settings', 'handler_settings', 'target_bundles'], NULL);
    }

This is not a big problem, as the 'target_bundles' form element is #required anyway, so the case that an empty array is in the values to be validated may never occur. Even more, this means these lines should not be there.

This issue was split off #2429699: Add Views EntityReference filter to be available for all entity reference fields: Add Views EntityReference filter to be available for all entity reference fields.

Issue fork drupal-3061180

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Pancho created an issue. See original summary.

pancho’s picture

Status: Active » Needs review
StatusFileSize
new1.25 KB

Status: Needs review » Needs work

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

kunalgautam’s picture

Assigned: Unassigned » kunalgautam
kunalgautam’s picture

StatusFileSize
new1.25 KB

Patch for Drupal 9.1

kunalgautam’s picture

Assigned: kunalgautam » Unassigned
Status: Needs work » Needs review
joachim’s picture

> For security reasons, we took the explicit design decision that if no target bundle is configured, we shouldn't fall back to allowing all bundles.

Could the link to the issue for that change be added to the issue summary please?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Postponed (maintainer needs more info)

Per #9. I can't find it but fairly positive there is a newer ticket for this too.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

#1978714: Entity reference doesn't update its field settings when referenced entity bundles are deleted was the issue this code was added to, but don't see anything in that ticket about this being a security issue. So can the issue where this was a security issue? If no follow up I say we close out.

joachim’s picture

The documentation around the NULL/[] difference for target bundles was updated in another issue about a year ago. IIRC it got fixed, so there should be an explanation in code now.

smustgrave’s picture

So should this be closed now? or rescoped.

joachim’s picture

Status: Postponed (maintainer needs more info) » Needs work

Needs a rescope.

    // If no checkboxes were checked for 'target_bundles', store NULL ("all
    // bundles are referenceable") rather than empty array ("no bundle is
    // referenceable" - typically happens when all referenceable bundles have
    // been deleted).

but:

      $form['target_bundles'] = [
        '#type' => 'checkboxes',
        '#title' => $entity_type->getBundleLabel(),
        '#options' => $bundle_options,
        '#default_value' => (array) $configuration['target_bundles'],
        '#required' => TRUE, <-- it's required

So AFAICT you can't submit the form with nothing checked anyway, and thus the whole of that validation callback can be removed.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

pancho’s picture

Title: Don't allow all bundles if no target bundle is configured » Remove superfluous target_bundles form validation for entity types with bundles
Issue summary: View changes
pancho’s picture

Issue summary: View changes
Priority: Minor » Normal

pancho’s picture

Status: Needs work » Needs review
Issue tags: +Needs change record

For BC reasons, I chose to deprecate the validator rather than removing it altogether.
However I added a warning against use in contrib and custom code, as it's outright wrong, not just superfluous.
Ready for review, I guess.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new1.25 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.