couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Tyler <...@8thfold.com>
Subject Re: ok so I've introduced myself - here is problem one
Date Sat, 21 Aug 2010 14:37:02 GMT
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.

When a user accesses a database, then his/her credentials (name and
password) are used to dynamically determine his reader names. The user
credentials are input to a javascript function and the function returns a
list of names for the user, or an error if the user credentials are wrong.

When a document is protected by reader access lists, any user attempting to
read the document must be listed. Reader lists are enforced in views too.
Documents that are not allowed to be read by the user are dynamically
filtered out of views, keeping the document row and extracted information
invisible to non-readers.

-- from the wiki, where i always have a hard time finding things  ... AND
_admins -> _security

The /db/_admins handler has been removed and replaced with a /db/_security
object. Any existing _admins will be dropped and need to be added to the
security object again. The reason for this is that the old system made no
distinction between names and roles, while the new one does, so there is no
way to automatically upgrade the old admins list.
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<http://wiki.apache.org/couchdb/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 <faculty@gydos.com> 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
>

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