Intercepting HTTP Requests

[Ronnie Royston]

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?

--

[ermouth]

Consider using _rewrite as a function, see
https://docs.couchdb.org/en/stable/api/ddoc/rewrites.html#using-a-stringified-function-for-rewrites
for
more details.

ermouth


On Sat, Jul 8, 2023 at 10:28 PM Ronnie Royston <ron...@ronnieroyston.com>
wrote:

[Robert Newson]

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.

[Ronnie Royston]

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.

--
Ronnie Royston
(504) 460-1592

[Robert Newson]

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.

[ermouth]

> The aim is to implement a least privilege model

To achieve that with _rewrite you very likely still need at least a simple
proxy, which will redirect most or all inbound requests to a particular
_rewrite endpoint. This case R.Newson’s argument doesn’t stand, rewrite
becomes mandatory.

As for creating DBs – that’s right, user can’t create DBs without being an
_admin.

As for deprecation – about 80% of QS methods are deprecated, anyway they
are useful and there’s no reason not to use them. Porting _rewrite to
node.js is pretty straightforward if needed.

Hope it helps.

ermouth

[Ronnie Royston]

That does help. When I (re) consider porting/fwd'ing/piping from Couch to
Node back to Couch it seems clear:

Node.js (or other server/service) in front of Couch and end users have no
direct access to Couch. Ever. End of story CouchDB authentication story.
And that's OK. CouchDB is still a great DB product. You just have to roll
your own auth proxy.

Took me about a week of research to arrive there.

[Ronnie Royston]

Each *document* OR *field* gets a security object, e.g. "s" below,
corresponding to CRUD vis a vis HTTP verbs. Keep It Simple Stupid, KISS
principle. https://en.wikipedia.org/wiki/KISS_principle

{
"_id": "b7e07b751d8679044f4e49d166000031",
"_rev": "4-3a82e30d9a3544f5ea8314a847b3b317",
"s": {
"put": [
"user1",
"user2"
],
"get": [
"public"
],
"post": [
"user1",
"user3"
],
"delete": [
"user1",
"user2"
]
},
"foo": {
"hello": "world",
"s": {
"put": [
"user1",
"user2"
],
"get": [
"public"
],
"post": [
"user1",
"user3"
],
"delete": [
"user1",
"user2"
]
}
}
}

On Sat, Jul 8, 2023 at 4:14 PM Ronnie Royston <ron...@ronnieroyston.com>
wrote: