Ok, thanks - so if no one complains, I'll implement this by the end of the week.
I really would love to finally get a new Sling API release out, it has been a long time since the last one... Regards Carsten 2014/1/15 Mike Müller <[email protected]> > Although this seems to be another compromise, it has advantages to > the actual flag which must be set on every provider. Sorry to say it > again, but no configuration would be easier and logical. The writer > of the ResourceAccessGate can decide anyway on which Resource he > will apply rules or not. That's one reason why the return value of the > methods on ResourceAccessGate is GateResult which has three states: > GRANTED, DENIED, DONTCARE. The last means that the ResourceAccessGate > does not handle this resource. > > So a +0.5 from my side. Which means it is better than the status quo. > > The implementation of ResourceAccessSecurity respects already the > service ranking of the ResourceAccessGate implementations as suggested. > > > Best regards > mike > > > > -----Original Message----- > > From: Carsten Ziegeler [mailto:[email protected]] > > Sent: Wednesday, January 15, 2014 12:43 PM > > To: [email protected] > > Subject: Re: Reconsidering when to apply resource access security > > > > So to redefine my proposal, we define a service registration property > > "CONTEXT" for a ResourceAccessSecurity - if not set it defaults > "provider", > > allowed values are "application" and "provider" - if an invalid value is > > used, the service is ignore (and this is logged as error). > > > > All ResourceAccessSecurity services marked with context "provider" are > > chained with lowest service ranking first and invoked for all resurce > > providers which indicate they don't have own security checks. > > All ResourceAccessSecurity services marked with context "application" are > > chained with lowest service ranking first and are always invoked. > > > > While I don't expect to have more than a single resource access security > > service for each context, chaining them makes imho sense and gives a well > > defined execution order. > > > > WDYT? > > > > Carsten > > > > > > 2014/1/15 Carsten Ziegeler <[email protected]> > > > > > 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 > > > > > > > > > > > -- > > Carsten Ziegeler > > [email protected] > -- Carsten Ziegeler [email protected]
