rewrite functions are also optional. a user with access to call the _rewrite endpoint could simply PUT /dbname/docid instead. You'd need external enforcement to ensure they did not do so. _rewrite is also deprecated.
Only admins can create (or delete) databases, and ordinary users should not be granted admin rights. B. > On 8 Jul 2023, at 21:03, Ronnie Royston <[email protected]> wrote: > > The aim is to implement a least privilege model, i.e., each user is granted > the minimum system resources and authorizations that they need. > https://csrc.nist.gov/glossary/term/least_privilege > > Will try it with _rewrite as a function. > > In addition to per document authorization, what limits a user/member from > creating an infinite number of databases? It seems like a native rich auth > model could be built with a *request function* having req, oldDoc, newDoc, > userCtx, and secObj *but* for max power the verify function would also need > to call/request other endpoints, for example, .length of GET all db with > owner/author = userCtx.id/sub in order to limit db's per user. > > On Sat, Jul 8, 2023 at 2:41 PM Robert Newson <[email protected]> wrote: > >> 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 <[email protected]> >> 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? >>> >>> -- >> >> > > -- > Ronnie Royston > (504) 460-1592
