You could do that pretty easily, either using query-based entitlements or the builtin security model - or even a hybrid of the two. I'd use the builtin security model if it fits, and only use query-based entitlements if there's a roadblock that can't be knocked down.
With builtin security I'd start with one role per user, so user Alice would have the role Alice. User Bob would have the role Bob. Both would also have a generic application-user role: call this whatever you like. Each user-role has default permissions granting read, update, insert for that same role. Then you'll want documents placed into the Shared directory to automatically add read permission for the application-user role. That could be done in upload code: xdmp:document-insert takes a permissions parameter, and that could be `(xdmp:default-permissions(), xdmp:permission($SHARED-ROLE, 'read'))`. You could also use directory inheritance to handle that. I would only do that if I could get it to work with directory-creation=manual, calling xdmp:directory-create and adding directory permissions as part of creating a new user. If you need to support self-service registration you could create the user and the new shared directory in an amp function. Using query-based entitlements would also work. In that case you'd simply know that every user directory is '/users/'||$user-id||'/' and every shared directory is directory is '/users/'||$user-id||'/Shared/' - or something along those lines. At query time, build cts:directory-query terms from those directory URIs and use them to restrict access. As already noted the main risk is that with entitlements it's up to you to make things secure. The door is unlocked unless you lock it, and often apps like this will run everything as an admin user. With the builtin security models the door is locked by default, unless you're the admin user. You can mix these approaches, too: create a reader role and a writer role, and use default permissions to grant them to all documents. Then most operations can run in the reader role and use entitlement queries, while special operations use functions that amp to the writer role. -- Mike On 30 Jul 2014, at 03:25 , Timothy W. Cook <t...@mlhim.org> wrote: > Mike, > Thanks for this insight. I posted another reply based on yours and Danny's > help so far. One specific thing not in that reply is about your comment > regarding entitlements. In my updated description of the use case I stated > that any documented in the 'shared' directory could be read by anyone that > the user chooses. So, I am not sure that I would need a document to record > relationships in this scenario. Your thoughts? If something is still needed > could this be done with document or even directory properties? I understand > that there are trade offs for each choice. I estimate that the average user > will have between 2000 - 3000 documents in this shared directory and will > share them with, at most 100 other users. Documents sizes will range between > 100kb and 500kb. > > Thanks for your help. > > Cheers, > Tim > > > > On Mon, Jul 28, 2014 at 7:50 PM, Michael Blakeley <m...@blakeley.com> wrote: > In the builtin security model, simply adding a collection to a document won't > make that document visible to another user. Visibility of documents is > controlled by read permissions and roles. Granting read permission for a > document to a role makes that document visible to users that have that role. > > Using the builtin security model, each user would have its own role, and the > default permissions would include insert, read, and update for that role. > Users could also grant permissions to other user roles. > > However that might not be optimal for some of your most common use-cases. > First, re-sharing could get tricky. Re-sharing a document by changing its > permissions requires updating it. That may be the trickiest part of your > implementation, because if I have update permission I can make any other > changes too. That might lead you to use an amp'd function for resharing, and > you might have to tracking sharing state outside the builtin security model. > Adding some document properties might take care of that. > > Also it's not clear to me how your users will think of these "collections". > But let's say they look and act like folders or directories. With dropbox, > for example, I can share a specific document or an entire folder. If I create > a new document in a shared folder, that's also shared. That would work if you > enable inherited permissions using the built-in security model, or using > extra code in your upload function. However automatic inheritance requires > directory fragments. But enabling automatic directory creation can be a > bottleneck for concurrent updates. Maybe you could get away with > directory-creation=manual, and call xdmp:directory-create only when sharing a > directory. Or implement your own inheritance code that runs whenever a new > document is created, and maintain your own documents that record sharing > relationships. > > Extending that idea, another approach is to maintain your own pseudo-security > model. This is sometimes called "entitlements". This is closer to how dropbox > works, and it has pros and cons. You have more flexibility, but any bugs in > your code risk revealing documents that ought not to be shared. In this model > you would maintain your own documents that record sharing relationships. When > requesting a document or directory you'd use that sharing information to > build a query using cts:document-query, cts:directory-query, and perhaps even > cts:collection-query. The query results will only include documents that the > user is authorized to see. This is very similar to how the built-in security > model works, but using your own data model rather than directory fragments. > > -- Mike > > On 28 Jul 2014, at 07:18 , Timothy W. Cook <t...@mlhim.org> wrote: > > > I am in the early design stages of a (hopefully) large application and > > would like to see if I understand the operations of collections correctly. > > > > You can think of this in a similar context to a social media app. > > I have attached a simple diagram to aid the text. > > > > Imagine that Joe, Sue and Tom are users and each have a collection (marked > > 'P' )where only they have read/write access to documents they load. > > Joe and Tom have collections that they would like to use to share (read > > only) with various other users, one being Sue. This seems rather straight > > forward. > > However, the use case also calls for Sue being able to share (read only) > > Tom's documents with Joe and Joe's documents with Tom; as she sees fit > > without the intervention of Tom or Joe. > > > > Could someone expand on this to describe how this might be setup? Do I > > need separate roles that are tied to each collection, for each of these > > exchanges? > > > > Thanks, > > Tim > > > > > > -- > > > > ============================================ > > Timothy Cook > > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > > MLHIM http://www.mlhim.org > > > > <Collections.png>_______________________________________________ > > General mailing list > > General@developer.marklogic.com > > http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > General@developer.marklogic.com > http://developer.marklogic.com/mailman/listinfo/general > > > > -- > > ============================================ > Timothy Cook > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > MLHIM http://www.mlhim.org > > _______________________________________________ > General mailing list > General@developer.marklogic.com > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general
