Hi, I would love to move forward with this one.
I think Felix raised some valid concerns about the API which could be fixed easily. In addition (as I wrote in the bug), I think the API should go into a separate package. Main reason is package versioning. The resource package is already overloaded: we have the resource resolver/factory and providers in there and a change to one of those interfaces increases the minor version number (semantic versioning) of the package. This in turn requires to update all implementors of interfaces from such a package. So whenever we make changes to the resolver, we have to re-release the providers. Not very nice. Adding another interface (the gate) to this set which usually is implemented by different bundles than providers or the resolver, we make this even worse. Then we have the issue of whether to put the support for this into the resource resolver bundle or not - while I see the point for keeping it separate, I think it is a central piece of the resource resolving infrastructure, so it's not really different from that pov than the crud stuff we added or maybe vanity urls. We never even talked about putting this stuff into a separate bundle. And I really don't want to open doors for everyone to overload a resource resolver (like with the customizer proposal). So do we really have an issue with putting this into the resource resolver bundle? Especially as it has no performance or feature impact if not used. As Felix also pointed out, we need to look at the implementation and see what needs to be done. Finally, although this feature is optional and has no impact if not used, there are valid concerns that this might be easily abused. But we can't prevent anyone from abusing stuff and we already have various places where people do funny things. One could argue that the resource access gate is worse because its about security. However, the gates only filter and do not bypass ACL checks. So if a user can't see a resource due to ACLs, there is no way to make this available through the gate! We discussed this feature many times, so I really don't want to repeat all this again. But we could add a configuration switch to the resource resolver factory whether gates are respected or not - we can even set the default to false, so we have an additional conscious decision inbetween. This would also make trouble shooting easier: once a resource is not visible etc you can simply turn off the gates by pressing the switch and see if its due to the gates. WDYT? Regards Carsten -- Carsten Ziegeler [email protected]
