I am afraid that it is not supported in CouchDB for now; rgds, canal
________________________________ From: Paweł Stawicki <[email protected]> To: [email protected] Sent: Mon, December 21, 2009 3:48:01 PM Subject: Re: Application security model What I need, is right at database level. I don't want to put permissions on every document, but for database. Is it possible? Best regards -- Paweł Stawicki http://pawelstawicki.blogspot.com http://szczecin.jug.pl http://www.java4people.com On Mon, Dec 21, 2009 at 01:29, go canal <[email protected]> wrote: > somewhere you got to keep users' authorization information, inside or outside > CouchDB. both works. > I think there are two types of actions: > - what a user can do with existing documents (read, modify, delete) > since this is for a specific document, we can have some attribute to > indicate the permissions. RBAC maybe one good choice. let's say, we have a > Roles attribute with a list of roles permitted. Then user-role mapping is > stored somewhere. > - for creating new documents > Similarly, we need to keep this permission somewhere, if we follow the RBAC > design above, it seems to me that keeping the RBAC outside of CouchDB is a > better choice: > you can have RBAC info in a sql table. each user has one or more roles; > each role has permissions; then each document in CouchDB has a list of > permitted roles. > rgds, > canal > > > > > ________________________________ > From: Manuel Schölling <[email protected]> > To: [email protected] > Sent: Sat, December 19, 2009 8:47:48 PM > Subject: Application security model > > Hi there, > > I'm just starting off with couch db. > > There is something I'm wondering about: how should I implement the > authorization to access a document. > > >From an outsider's view, one would use HTTP's authorization method when > using any PUT/GET/POST/DELETE requests. > But (as I understand it correctly) this mechanism is just available for > couch db administrator accounts. > > So how should I implement a web application security layer? > Is there any panacea? > > On could add a security field that includes ACL data to each document. > Then any update validation, view and list must check this data against a > user id and password that must be included in the REST request. > > Or should you really create one couch db admin account for each user? > (I'm referring to a web application end-user here)
