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. 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.
Whether we should use the gate for the feature flag implementation is a different thing then and can be discussed in another thread :) 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]
