Hi Am 14.01.2014 um 00:27 schrieb Carsten Ziegeler <[email protected]>:
> Ok, so let's seprate the two things for the sake of th discussion - as soon > as someone wants to have a resource access gate applied to all resource > providers (for whatever reason), this really becomes tedious, especially as > you have to know and configure each and every resource provider and set the > flag accordingly. No that's not the right background for the configuration flag: The background was, that a ResourceResolver indicated with this flag, whether it does its own access control (as JCR Resource Provider does) or does not and thus would benefit from general service. > In the last 6 months we encountered at least two use cases where it would > make sense to enable the gate in front of the jcr provider as there is no > way to cover the use cases with ACLs (I would need to dig up the details) > And as has been discussed at length, the gate is an additional check, so > you can't make stuff visible which is not visible from the provider. The access gate is a general access controller. Visibility is another yet overlapping problem: One part of visibility is the access right to read (or list) something. Another part is an application decision to hide something even though access control would grant access. So, we have two cases where this surfaces: Which one (apart from the feature flags ?) ? Maybe we should come up with an additional model ? > > Whether we should use the gate for the feature flag implementation is a > different thing then and can be discussed in another thread :) Sure thing. Regards Felix > > Regards > Carsten > > > 2014/1/13 Felix Meschberger <[email protected]> > >> -.5 >> >> Not exactly vetoing but: This creates and overlap in resource providers >> which effectively do access control (such as JCR Resource Provider) and as >> I said before: the feature flag is not a good candidate for the security >> system. >> >> After all the feature flag does visibility but no access control as in >> "can-write", "can-delete", "can-create", etc. >> >> Regards >> Felix >> >> >> Am 13.01.2014 um 06:24 schrieb Carsten Ziegeler <[email protected]>: >> >>> Hi, >>> >>> after long discussions we have to the compromise to tag a resource >> provider >>> if a (optionally) available resource access security is used for this >>> provider. >>> >>> I think this was a wrong compromise with no real value - and we should >>> remove this additional flag and simply always apply the checks. >>> One main driver is the new feature flags implementation which requires >> the >>> additional checks for all providers to properly work - and it would be a >>> maintenance nightmare to enable the flag on all providers (default is >> off). >>> >>> So, if no one complains with a good reason I'll do the change >>> >>> Thanks >>> Carsten >>> -- >>> Carsten Ziegeler >>> [email protected] >> >> > > > -- > Carsten Ziegeler > [email protected]
