You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Paul Gydos <fa...@gydos.com> on 2010/08/21 10:13:12 UTC

ok so I've introduced myself - here is problem one

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

Re: ok so I've introduced myself - here is problem one

Posted by Cliff Williams <cl...@aol.com>.
Paul,

Take a look at this

http://couchapp.org/page/authn-preview  which is a good write up.

Best regards

Cliff


On 21/08/10 09:13, 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
>
>    

Re: ok so I've introduced myself - here is problem one

Posted by J Chris Anderson <jc...@apache.org>.
Paul,

This screencast may help as well:

http://www.youtube.com/watch?v=oHKvV3Nh-CI


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<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 <fa...@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
>> 


Re: ok so I've introduced myself - here is problem one

Posted by Kenneth Tyler <ke...@8thfold.com>.
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 <fa...@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
>