It is a universal truism that for security to work, you have to do it correctly :)
On Fri, Oct 21, 2011 at 10:26 AM, Ardaman Grewal <[email protected]> wrote: > Thanks for the replies so far, appreciate it. > > One of the reason for multi-subscriber/multi-repository, is the system will > be a multi-tenant system. Managing access just via security will involve > quite a bit of security and access management. And you have to get it right > so you don't allow subscriber A to look at subscriber B's data. Also, when > you turn on versioning, that is repo global, therefore more security > management. > > > On Fri, Oct 21, 2011 at 9:09 AM, Justin Edelson > <[email protected]>wrote: > >> Indeed, but that's not to say that a repository per subscriber is :) >> Access Control is the way to do what you want to do. >> >> That said, AFAIK, there's no reason you can't have multiple >> repositories per VM as long as each point to a different directories >> and (if you're using a database-backed pm) different table spaces. >> It's just not typical and seems very heavyweight for what you want to >> do. >> >> Justin >> >> 2011/10/21 Fabián Mandelbaum <[email protected]>: >> > I thought that different-workspaces-for-each-subscriber (read: user) >> > was discouraged by David's Model Rule #3: >> > >> > http://wiki.apache.org/jackrabbit/DavidsModel >> > >> > On Fri, Oct 21, 2011 at 10:45 AM, Gustavo Henrique Orair >> > <[email protected]> wrote: >> >> What about using different workspaces for each subcriber? >> >> >> >> >> >> 2011/10/20 Ardaman Grewal <[email protected]> >> >> >> >>> I am trying to design and implement a version-able document system that >> is >> >>> meant for multiple subscribers of the system. Data for each subscriber >> has >> >>> to be isolated from each other. A Web app will provide REST API for the >> >>> client applications to access data. Web app will also handle some of >> the >> >>> security and subscription aspects of the subscribing users. I have been >> >>> considering Jackrabbit for data management and versioning backed by a >> >>> relational database. For the web app, thinking of hosting it in Tomcat. >> >>> Hopefully, the following figure comes through properly formatted. In >> case >> >>> it >> >>> doesn't, it shows a web app which layers a REST api on top of multiple >> >>> (separate) JR repositories. >> >>> >> >>> Is this a correct approach? Is Jackrabbit intended to be used like this >> or >> >>> am I in the weeds? Any other suggestions. >> >>> >> >>> Thank you very much. >> >>> >> >>> >> >>> >> >>> +-----------+ >> >>> | | >> >>> +------+ | | >> >>> +--------------+ >> >>> +------>|Repo A|<---------->| Web |<--------> | Subscriber >> A | >> >>> | +------+ | App | >> +--------------+ >> >>> | | Exposes | >> >>> | | REST | >> +--------------+ >> >>> | +------+ | Svcs |<--------> | Subscriber >> B | >> >>> +------>|Repo B|<---------->| | >> +--------------+ >> >>> | +------+ | | >> >>> | | | >> >>> | +-----------+ >> >>> \|/ >> >>> +------------+ >> >>> | one or more| >> >>> | RDMS Store | >> >>> +------------+ >> >>> >> >> >> > >> > >> > >> > -- >> > Fabián Mandelbaum >> > IS Engineer >> > >> >
