2011/11/23 Vidar Ramdal <vidar.ram...@webstep.no>: > 2011/11/23 Mike Müller <mike...@mysign.ch>: >> I think the discussion here is missunderstood. It's neither about >> to redefine existing ACLs nor about reinventing something already >> existing. It's just about introducing hooks or entrypoint to let >> developers define some other access controlling rules if needed. >> Sling will NOT have to deal with permissions or policies, users and so >> on. That's all up to the developer which want's to use the hooks. >> So if you're are fine with the ACLs from JCR, you don't have to >> change anything, if you are not, this would give you the chance >> to solve your problem (like my example to give access to a >> resource from 8.00 to 17.00). >> So >> It would help not only for special rules like the one above, it would >> also help to handle access controlling on resources which are provided >> from another resource provider than JCR, like the file system provider, >> where no access controlling can be attached today. > > Being picky here: We could provide access control by extending the > file system provider to support it. And your example of > time-restricted access could be implemented in Jackrabbit's existing > AccessManager.
Yepp, right - looking at Felix recent proposal which basically does this, this is an option. And I agree that we should consider this option; it has advantages but on the other hand requires that a resource provider implements all potential use cases. If we take Mike's example, you definitely don't want to implement those checks in each and every provider. The use case I had in my is the file system provider. In order to have checks working with a file system you would need to have the same user for the server than you have for the webapp - which is something you definitely don't want. So you need a different check here which should be a generic solution as the real check really depends on your application. That's where my suggestion is coming from. And I could imagine similar use cases for other providers. One solution would be that some providers define their own service interface where you could hook into. Use cases like Mike's could be solved with a ResourceDecorator - at least for reading, delete and update. As we don't have crud yet, we have to see how this can be solved there. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
