2014/1/14 Felix Meschberger <[email protected]> > 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. > > Yes, right - and the flag defaults to "provider does own access control".
> > 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 ? > Ok, I see your point - you're saying we need one mechanism to apply access control to resource provider which do not have their own access control - this is kind of a "low level" mechanism. And we have the application level which adds additional checks across the whole resource tree, like hiding resources etc. If we're talking about the interface, I would assume that they both like pretty similar - controlling visibility on the app level might be one use case, but preventing write access might be another one etc. Right now we use the ResourceAccessSecurity for the first case. What about defining a registration property for this service, something like "context"? By default this is "provider" and the service is applied to the providers indicating they need additional access control. And if its set to "application", the checks are applied on top at a higher level? Regards Carsten
