Content authors cannot see components

Do we need a generic "Use Experience Builder" permission which we'd use for the XB route and would move the components behind it? Otherwise it is pretty complicated to figure out when users should have access to the components.

In the ticket 📌 Provide granular permissions for pages Active there were these 3 permissions (create, edit and delete).

As I didn't have any option for overview or a general "administer", I could only use "edit xb_page" as the permission to use whenever a editor wants to edit it.

Maybe I was mistaken or maybe it's not clear.

✅ Config entity access control handler

The Component config entity type uses \Drupal\experience_builder\EntityHandlers\ContentCreatorVisibleXbConfigEntityAccessControlHandler, which has:

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

(since 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active )

✅ Route definition's requirements

The culprit is

experience_builder.api.config.list:
  path: '/xb/api/config/{xb_config_entity_type_id}'
…
  requirements:
    _permission: 'administer themes'

Choices

Either:

1. Remove the route requirements altogether and rely on its individually checking access:
   

       // As config entities do not use sql-storage, we need explicit access check
       // per https://www.drupal.org/node/3201242.
       $config_entities = array_filter($config_entities, fn(XbHttpApiEligibleConfigEntityInterface $config_entity) => $config_entity->access('view'));
   

2. Or defining a collection_permission, which is why the Block config entity for example has
   

     collection_permission: 'access block library',
   

   I don't think we want any net new permissions though. 😅

IMHO the simplest approach is this:

diff --git a/experience_builder.routing.yml b/experience_builder.routing.yml
index fde9ce0a3..cb10b697d 100644
--- a/experience_builder.routing.yml
+++ b/experience_builder.routing.yml
@@ -130,7 +130,6 @@ experience_builder.api.config.list:
   defaults:
     _controller: 'Drupal\experience_builder\Controller\ApiConfigControllers::list'
   requirements:
-    _permission: 'administer themes'
     # 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

Because

    # 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'

already ensures no anonymous users can access it. That was added by 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active and it seems a simple oversight that that the _permission part was not removed?

I’ve created a merge request that removes the `_permission: 'administer themes'` requirement from the `experience_builder.api.config.list` route, based on Wim Leers’ suggestion in comment #10.
This allows content editors with the proper `xb_page` permissions to view and place components without needing the `administer themes` permission.
The route is still protected by `_user_is_logged_in: 'TRUE'` and per-entity `access('view')` checks, so there are no security risks introduced.

Tested and confirmed:
Before fix: Component list was not visible for content editors.
After fix: Component list is visible and components can be placed.

Attaching screenshots of before and after the fix for reference.

Only thing I'm thinking about is now that we've removed this permission. The authors(who don't have administer code components) cannot see any code components. They can just see the components. If the code components are added to the components, it'll start throwing 403 for such users.

So maybe we should update JavascriptComponent to also use ContentCreatorVisibleXbConfigEntityAccessControlHandler access handler.

+1 use ContentCreatorVisibleXbConfigEntityAccessControlHandler, that organically happened in 🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities Active

I think this should be PPed on 🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities Active (which should be ready to land if RTBCed).

Re #9: A `collection_permission` might be unavoidable. See #3525572-11: Implement OAuth2 authentication for API endpoints related to code components → where Bálint has issues with oauth, and we might want to remove the _user_is_logged_in

Thanks, @penyaskito, for highlighting this issue for me. After our discussions, I'm now unblocked with regards to the _user_is_logged_in access checker and other permissions — see my summary here: #3525572-13: Implement OAuth2 authentication for API endpoints related to code components → .

Since 🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities Active landed, can we close this as outdated because the access handler has changed? Per #18 & #20 it seems like it?

No, we still need to do that. The access handler has changed, but the 'administer themes' permission is still there in the route access requirements.

Rebased, if it passes tests it's RTBC.

I have a preference for a collection_permission as mentioned in #9 🐛 Content authors cannot see components Active .2, but Wim has a preference for the proposal at #9 🐛 Content authors cannot see components Active .1 (the current implementation). As apparently the _user_is_logged_in is not a blocker anymore for [#16136330], we can leave this as is, and decide later if we need (or not) a follow-up.

Looks good to me! Tests now reflect the fact the permission is not needed.

Seems like the collection_permission should be a follow up discussion since _user_is_logged_in isn't a blocker. And I know XB has gone for less verbose permissions and adding a collection permission for each config would break that paradigm.

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

Follow-up at 🐛 `api.config.auto-save.get` route returns data without any authentication Active