`api.config.auto-save.get` route returns data without any authentication

I just realized that I meant to open the issue for api.config.get, that's where I originally discovered the problem. I haven't tested api.config.auto-save.get, so let's be sure to check that, too.

I just realized that I meant to open the issue for api.config.get, that's where I originally discovered the problem.

That shouldn't be the case:

experience_builder.api.config.get:
  path: '/xb/api/v0/config/{xb_config_entity_type_id}/{xb_config_entity}'
  defaults:
    _controller: 'Drupal\experience_builder\Controller\ApiConfigControllers::get'
  requirements:
    _xb_http_eligible_config_entity: 'TRUE'
    _entity_access: 'xb_config_entity.view'
    # Allow a subset: `Component` config entities are read-only via the internal HTTP API.
    xb_config_entity_type_id: '(pattern|js_component|xb_asset_library)'

AFAICT this is simply questioning 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active 's introduction of explicit access for all → ?

IOW: authentication & authorization are present, authorization is simply granted very broadly.

I suspect what we want is the _user_is_logged_in thing 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active did for experience_builder.api.config.list:

experience_builder.api.config.list:
  path: '/xb/api/v0/config/{xb_config_entity_type_id}'
  defaults:
    _controller: 'Drupal\experience_builder\Controller\ApiConfigControllers::list'
  requirements:
    # Any internal HTTP API-eligible XB config entity type.
    _xb_http_eligible_config_entity: 'TRUE'
    # But deter users from trying to access other config entities via this route: this ensures 404 responses rather than
    # 403.
    # @see \Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testNonXbConfigEntity()
    xb_config_entity_type_id: '(component|pattern|js_component|xb_asset_library)'
    # The UI client can fetch all the components the current user has access too, regardless of which kind of XB-enabled
    # entity you're editing.
    _user_is_logged_in: 'TRUE'
  options:
    # Indicate that external applications may use this route. For authentication, see `modules/xb_oauth/README.md`.
    xb_external_api: true
  methods: [GET]

Because here's the thing: @lauriii wanted XB to both:

• only have a single simple "admin permission" per config entity type: JavaScriptComponent::ADMIN_PERMISSION etc.
• NOT have a catch-all "use XB" permission — see 📌 SdcController cleanup tasks Active 's functional requirements

See:

1. my write-up about about this at #3508694-14: Permissions for XB config entity types → .2
2. my very detailed write-up about the consequences of this at #3508694-19: Permissions for XB config entity types → .2
3. confirmed by @lauriii at #3508694-20: Permissions for XB config entity types →

Either we must do what I just pushed based on #4, or, and probably that's the safer option, \Drupal\experience_builder\EntityHandlers\VisibleWhenDisabledXbConfigEntityAccessControlHandler should be narrows to only logged in users rather than the current

      // We always allow viewing these entities, even if disabled.
      'view' => AccessResult::allowed(),

Actually, I think we can do both, but perhaps that means the first commit is now obsolete

Plus, we need to expand assertAuthenticationAndAuthorization() to facilitate testing GETting an unauthorized individual config entity (i.e. the new test coverage that this issue needs).

🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler bypasses admin permissions for view Active is in, which means we kinda don't need this test coverage here anymore … except that it would be good to generalize to all XB config entity types, instead of just Pattern.

Added tests for anonymous GET at assertAuthenticationAndAuthorization based on openapi examples, so we can generalize to all XB config entity types.

VERY nice work here, @penyaskito!

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