On Fri, Mar 8, 2013 at 8:53 AM, Ian Boston <[email protected]> wrote: > ...How will the ResourceProviderDecorator protect from navigating using a > native object of the ResourceProvider impl acquired using an adaptTo ?...
By native object I assume you mean a JCR Node for example? If yes you're right that whatever a ResourceProviderDecorator does to prevent access to a Resource, by adapting another Resource to a JCR Node you can bypass that. That's why several of us want to avoid using ResourceProviderDecorator or any similar mechanism for access control when using Sling over a JCR repository. As far as access control is concerned, I see three options for running Sling: 1) Running on a JCR repository - access control is fully delegated to the repository, maybe disabling ResourceProviderDecorator with a default configuration, to make sure people only use that if they know what they're doing. 2) Running on non-JCR content stores, and not caring about access control. There are valid use cases for that, especially if the content store is fed from a different system and Sling only has readonly access to it (think a Solr index that's fed from incoming media files for example). This is of course already doable today, as Sling does not do any access control by itself. 3) Running on non-JCR content stores which do not support access control, and implementing access control at the application layer. This is where ResourceProviderDecorator can help, and it can be as simple as saying "anonymous only has read access to /content and /static, other users have full read-write access" which can be valid combined with http front-end restrictions. What I definitely want to keep is the "if using JCR, don't use any other access control mechanism" constraint, and if people do otherwise it's their problem. You can probably work around that restriction today anyway, by implementing custom ResourceProviders that wrap existing ones, so why not make that clearer and make option 3) above possible. -Bertrand
