Hi, Currently there is no fine-grained read access controls within a database and our advice is to separate documents into different databases to achieve this level of control or, as you suggest, you can put such logic in an application or proxy that mediates all access to couchdb.
Show functions are optional, a user could simply call GET /dbname/docid and bypass any logic you might add there. as an aside, fine-grained _write_ access is supported, through the validate_doc_update functions. We are looking at enhancing this area of couchdb. That work exists at https://github.com/apache/couchdb/pull/4139 and has recently seen some significant activity that raises the odds of it landing in a future couchdb release. We'd benefit from knowing if it would address your needs. hth, B. > On 8 Jul 2023, at 20:27, Ronnie Royston <ron...@ronnieroyston.com> wrote: > > I am a CouchDB user. I need more granularity in terms of DB authorization, > e.g. limit who can read a document in a shared database. > > It appears that show functions do get passed the request object, (doc, > req), however it looks like this is discouraged via a deprecation warning. > Update validation documents pass (newDoc, oldDoc, userCtx, secObj) to the > query server, however I need the request object, and for *all* HTTP methods. > > src/chttpd/src/chttpd_node.erl seems to handle HTTP requests but I do not > know Erlang well enough to pipe all requests out. I would really like to > allow clients/browsers to communicate directly with couch (albeit via > recommended reverse proxy) and not force all db requests through, for > example, Node.js. > > It seems like the query server architecture is 99% there in terms of what I > need - it's just that I need the full request object and need my validation > to get called for every HTTP method. > > How can I restrict access to a document in a shared database based on > userID? I believe I need to intercept HTTP requests and validate them, > right? > > --
