incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <>
Subject Re: ok so I've introduced myself - here is problem one
Date Sat, 21 Aug 2010 23:35:25 GMT

This screencast may help as well:

On Aug 21, 2010, at 7:37 AM, Kenneth Tyler wrote:

> Paul,
> This may be one way to do what you want:
> Reader Access
> To protect document contents, CouchDB documents can have a reader list. This
> is an optional list of reader-names allowed to read the document. When a
> reader list is used, protected documents are only viewable by listed users.

this bit about per-document access control is out of date and misleading. sorry about that.

the later stuff is correct:

> The security object has 2 special fields, admins and *reader*s, which
> contain lists of names and roles which are admins or *reader*s on that
> database. Anything else may be stored in other fields on the security
> object. The entire object is made available to validation functions.
> and this, under "security features overview"
> As of CouchDB 0.11, three types of users can be defined:
>   - database readers - Defined per database. They can read all types of
>   documents from the DB, and they can write (and edit) documents to the DB
>   except for design documents.
>   -
>   database admins - Defined per database. They have all the privileges
>   readers have plus the privileges: write (and edit) design documents,
>   add/remove database admins and readers, set the database revisions limit (
>   */somedb/_revs_limit* API) and execute temporary views against the
>   database (*/somedb/_temp_view* API). They can not create a database and
>   neither delete a database.
>   - server admins - Defined per CouchDB server. They have all the
>   privileges.
> Server admins are defined in the *admins* section of the .ini configuration
> files. See Setting_up_an_Admin_account<>for
> more details.
> Database admins and readers are defined in the security object of a
> database. This security object, located under "/db_name/_security" in
> CouchDB version 0.11 and above, is a JSON document having the following
> structure:
> {
>  "admins" : {
>     "names" : ["joe", "phil"],
>     "roles" : ["boss"]
>   },
>   "readers" : {
>     "names" : ["dave"],
>     "roles" : ["producer", "consumer"]
>   }
> hope those help get you started... i haven't started working on
> security myself yet.
> ken tyler
> }
> On Sat, Aug 21, 2010 at 1:13 AM, Paul Gydos <> wrote:
>> I have a couchone instance.
>> I like the couchapp interface on couchone as far as not needing to be
>> anything but a novice to sign up and get started making a database and
>> entering information.
>> I started realizing that the database is there for the whole world to see
>> and then I realized that that anyone could become an administrator by
>> default with the 'admin party'.
>> So I snooped around for documentation and I think I could a basic grasp on
>> how to take the admin party away and how to add admin users.  (If I recall
>> correctly it was under Security);
>> However I couldn't find anything on how to limit the viewing of the
>> database
>> to anyone except the users and or the.administrators.
>> Is that beyond the scope of the couchapp on couchone? Would it have to be
>> hosted on an intranet, or does the instance have to be hosted elsewhere so
>> one could add additional protection in front of the couch.
>> I hope I can find an answer for couchone where viewing can be restricted
>> because I want to continue building my application with less concern for
>> the
>> details at this time and a solution which is hosted by experts for free is
>> ideal until I can make my projects profitable.
>> I've been on the listserv for weeks and weeks and seen no other concern for
>> this.
>> Please make responses with the assumption of little technical knowledge,
>> but
>> I can follow detailed directions and take detailed notes as to the results
>> of trying to implement suggestions.
>> Paul Gydos

View raw message