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

Created on 25 March 2019, almost 6 years ago
Updated 19 August 2023, over 1 year 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 about 2 hours 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.71.5 2024