Blocks' 'view' operation is interpreted as "render on page" instead of "read this config entity"

I'm wondering whether we could have different access checking depending on the format we want to render. I would argue ideally reading of block config entities via REST, would return exactly what you expect to return.

I'm not sure what this means?

Oh well, basically repeating the previous sentence. Check the view condition for the config entity instead of taking into account the plugin itself.

This is happening for BlockContent entities as well. And rather scary. Everything is exposed: from uuid to revision_id ..etc.

Responding to Wim's comment from that issue:

RE: #2820315: Blocks' 'view' operation is interpreted as "render on page" instead of "read this config entity" actually applying to all entity types — I can see why you'd interpret it that way, but I think that loses very important nuance. There's a key difference IMHO: nodes, comments, users, then view == "read the entity" == "render on page" (because the rendered representation is equivalent with being able to read all fields). But in the case of block entities (config entities), what's actually happening is not rendering the data stored in that entity — it's interpreting that data to render the associated block plugin in a particular place on the page. That's what makes block config entities special in this way.

As we already discussed once on IRC, I disagree with this (view == "read the entity" == "render on page" (because the rendered representation is equivalent with being able to read all fields)), as did you in this issue in comment #7/#8 :)

Content entities have plenty of layers between reading raw data and rendering an actual entity, at least 4 that can control visibility and how it is displayed:

1. Field formatters/view display configuration. Allows to control how a field is displayed and it's also very easy to hide one completely by just moving it to hidden. Entities often have internal data that is not meant to be displayed and this is the easiest way for users to do so.
2. Text formats convert e.g. embedded entities and many other things.
3. The process layer also allows to dynamically hide/show fields
4. Twig also makes it trivial to do a {{ content|without('some_field') }}.

None of that is reflected in field access. And we do offer all those API's, even I who knows that API well usually only bother with field access for fields that should only show dynamically based on access checks. And many developers probably just do checks in preprocess/twig.

All those steps can expose internal/private data. Especially since the rest module provides default configuration for node, so just by enabling rest, your site exposes all the raw data for its configurable fields on nodes to anyone. The example I also mentioned in IRC is a newspaper paywall. Those usually don't use field/node access as the user can view the node, but he'll just get a short teaser. If the site has REST enabled and you know that, it's easy to build a script to steal all their content.

So IMHO, the problem of viewing raw data vs. viewing what Drupal renders as the visual representation of that entity exists for all entities, content but also something like a view for example. As comment #7 said, all the "scary" internal data is out there in the open.

There is one thing where block is different from content entities. And that's that their raw data is usually just configuration of what should be displayed, so it's usually impossible to actually get the data you want to have displayed. For nodes, while there are plenty of issues as well, you can probably usually get something working despite all the "scary" stuff. But that doesn't mean it is not a problem.

So yes, possibly block and node require different solutions for what is technically the same problem and probably multiple issues.

I'm not sure how to solve those things. I guess a menu block should return a JSON/data representation of the menu tree for example? A block_content block the block_content entity (which then has the content-entity side of this problem)? A breadcrumb block the breadcrumb data? Maybe we need block plugin normalizers?