Add Permission Handling to ConfigPages Block Feature

I have created a patch.

I have completed the MR creation and Patch submission, so I am changing the status from “Active” to “Needs review.”

I have just noticed this issue too. I have the 'View the XXX config page entity' permission set to just one of my roles, but the anonymous user also sees the block. I have applied the patch, but the issue still persists. Drupal 10.4.0.

Is anyone else able to confirm if the patch is working or not for them? This is not working for me and all user roles are still able to view the configpage block.

This is a critical permissions bug. Any project developers available to review?

Thank you in advance.

Hello @lindsay.wils I've just tried to setup a fresh install of Drupal 10.4 + latest configPages with the patch provided

the patch does work for me. See the screenshot I've included the permission setup + screen of anonymous + authorized user. Can you please share some infor about your setup (the caching setting or modules enabled)? Maybe that will help us to identify the issue you have right now.

Thank you for confirming shumer. I have managed to work out my issues.

I was not rendering this block through a region, I was loading it programatically into a variable on my node, and rendering that variable in twig, which seems to be bypassing to permissions if rendered this way

$variables['custom_blocks'][$key]['block'] = $entityTypeManager
->getViewBuilder('block')
->view($custom_block);

Once added to the 'Content' region, this is working correctly now. Not sure if this is a bug in the permissions setup, or if this is the intended way of drupal working. I would have thought that no matter how you render the block into a page, the permissions still are honoured.

Thank you for taking the time to respond and help here.

In Drupal, rendering a block programmatically using the view() method on the block entity's view builder bypasses the usual access checks unless explicitly handled. This behavior occurs because rendering an entity directly focuses solely on generating its display output and does not automatically invoke the access checks associated with the block's entity or plugin.

To ensure the access checks are performed, you need to use the access method of the block entity before rendering it.

@shumer , @lindsay.wils
Thank you for confirming, reproducing the issue, and testing the patch.

As this is a critical permissions-related issue, I believe it would be beneficial to include the fix in the module if there are no objections from the maintainers.
Of course, I am open to any feedback or further discussions if needed.

I greatly appreciate your time and consideration on this matter.

Hey @umekikazuya I'm going to apply the patch and create a new release this weekend

@shumer
The latest release has been confirmed. Thank you for your prompt response and support.

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