Thanks Harry. I do not mind the effort on the front end if I know that performance will not take a hit. The roles/user seems like a useful approach.
On Wed, Dec 11, 2013 at 11:29 AM, Harry B. <[email protected]> wrote: > You haven't missed anything. The approach I have used many times is to > maintain roles for each user and have also modeled user "groups" the same > way. I recommend following a naming convention because at some point you'll > want to be able to build UI tools and will want to only show roles for the > app or have predictive names. > > What I mean is if my application is called "ABC", all my role names would > have a prefix like "abc-john-brown" > > One other consideration would be a role for each user to indicate the > owner, so for John Brown, I would have abc-john-brown role that is added to > documents John Brown shares from others and abc-john-brown-owner for all > documents that belong to John Brown. > > I know it seems like a lot of roles and duplicated effort, but what is > nice is that you can leverage solid, proven security on the documents > without and performance hit you'd take with controlling access using > application logic. > > Let me know if I can help. I've done this a few times and managed it with > SSO solutions as well. > > Harry > On Dec 11, 2013 6:13 AM, "Timothy W. Cook" <[email protected]> wrote: > >> I am planning an application and working on the security plan. >> >> Users will each have a collection to store their documents. At various >> times they will want to share some of these documents with other users. >> Typically read only. Having read through the vast amount of information, I >> still do not see where a document creator would be able to add read >> capability for a single user of a single document. The only approach I can >> see would be to create A LOT of different Roles. >> >> What have I missed? >> >> Thanks, >> Tim >> >> >> -- >> MLHIM VIP Signup: http://goo.gl/22B0U >> ============================================ >> Timothy Cook, MSc +55 21 94711995 >> MLHIM http://www.mlhim.org >> Like Us on FB: https://www.facebook.com/mlhim2 >> Circle us on G+: http://goo.gl/44EV5 >> Google Scholar: http://goo.gl/MMZ1o >> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> >> > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > > -- MLHIM VIP Signup: http://goo.gl/22B0U ============================================ Timothy Cook, MSc +55 21 94711995 MLHIM http://www.mlhim.org Like Us on FB: https://www.facebook.com/mlhim2 Circle us on G+: http://goo.gl/44EV5 Google Scholar: http://goo.gl/MMZ1o LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
