Hello all to the list. I was just in #couchdb on freenode discussing some concerns over read access on a public facing CouchDB server.
My major question is over controlling access to documents based on the goals of the application. I guess the best way would be to illustrate an example. I'm sure I bring a bit of baggage from the mysql way of things, so I apologize if I missed anything as I'm learning. That said, CouchDB really plugs in nicely with the ways I've been trying to bend other DBs in the past. Hopefully the suggestions that result will show that the lack of read level access control may be spurring some questionable design decisions (I'll gladly be wrong here as it would benefit me!). On with the example... -=- We have: ] Roles o Editors o Writers o Readers (authenticated, can comment or anonymous, strictly read only) ] Data o Articles o Comments ] Rules o Anonymous readers can read published documents. o Authenticated users can function as anonymous readers. o Authenticated users can comment on published documents. o Writers can function as authenticated readers. o Writers can read/modify/create their own unpublished documents. o Editors can function as authenticated readers. o Editors can read and modify unpublished documents. o Editors can publish/unpublish documents. -=- There are other designs that would fit in here, but I think this scenario covers the basics. The first snag I think that came up in my discussions on IRC is preventing the display of unpublished documents. The second snag is how do you manage users and their roles effectively without having to hand-edit files every time a change is needed? It was my understanding (again, correct me if I'm wrong!) that it is not currently possible to block read access to documents. Anyway, hopefully some good talks and maybe some ideas for improvements come of my questions here! Thanks for any input everyone, feel free to ask for clarification if any is needed. - Alex
