Allow marking a config schema types to be marked as "internal" (to avoid exposing them via HTTP APIs)

Created on 25 March 2019, over 5 years ago
Updated 19 August 2023, 10 months ago

Problem/Motivation

As of #3028301: Do not expose to Layout Builder's sections either in defaults or overrides to REST and other external APIs , Layout Builder is not yet ready to expose its "layout description data structure" as an API — that's what 📌 [PP-1] Expose Layout Builder data to REST and JSON:API Postponed aims to fix. As a work-around, we created \Drupal\layout_builder\Normalizer\LayoutEntityDisplayNormalizer to ensure this is not exposed via rest.module.

However, this then had to be repeated for jsonapi.module in #3042198: Add JSON:API integration test for LayoutBuilderEntityViewDisplay . But JSON:API module doesn't allow for such arbitrary
alterations, because it makes schema support impossible (see https://www.drupal.org/project/openapi ) and endangers JSON:API spec compliance.

Proposed resolution

Bring the internal flag from Typed Data definitions over to config schema as well, then we could just mark third_party_settings.layout_builder.sections as internal and the JSON:API module would respect that. We can make the RESTful Web Services module respect it too, and remove \Drupal\layout_builder\Normalizer\LayoutEntityDisplayNormalizer.

Remaining tasks

TBD

User interface changes

None.

API changes

Ability to mark

Data model changes

No changes, only an addition: a internal flag (name TBD) on config schemas would allow a certain subtree from the config schema to be marked as an internal implementation detail, that should not be exposed via HTTP APIs.

Release notes snippet

TBD

📌 Task
Status

Needs review

Version

11.0 🔥

Component
Configuration entity 

Last updated 19 minutes ago

Created by

🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺

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.

Production build 0.69.0 2024