On Wed, Jul 30, 2014 at 12:48 PM, Michael Blakeley <[email protected]> wrote:
> 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. > > That is my attitude. :-) > 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'))`. > > I am not sure I understand the application-user role usage here. Only users that Sue selects should have access to read her shared documents. Not all users. But yes, I see that the permissions capabilities are very robust and therefore require excellent application development documentation and careful implementation. > 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. > > Yes, self-service registration is a must. My plan is to just require a unique, validated email address and password. I do not plan to allow login via OAuth and other services. I will likely have a certain level of password requirement as well such as punctuation, numbers and mixed case. > 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. > Okay, this is where my thoughts were going as well. Good to see that it makes sense. > > 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. Not here, that is too scary. :-) I prefer explicit, not implicit. > 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. > Great! Thanks for the help. I have my development server setup now so I will be busy actually implementing some of these ideas and testing them. Cheers, Tim
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
