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 <[email protected]> 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 >>
