couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From go canal <>
Subject Re: Application security model
Date Tue, 29 Dec 2009 10:29:04 GMT
I am afraid that it is not supported in CouchDB for now;

From: Paweł Stawicki <>
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

On Mon, Dec 21, 2009 at 01:29, go canal <> 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 <>
> To:
> 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)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message