couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svein Helge Grinden <>
Subject Read access control
Date Sun, 26 Dec 2010 03:37:01 GMT

I have seen several discussion around read access pr document. One of the
bigger issues I have seen being discussed  is how to handle reduce
functions. Other issues would be replication and performance.

Have it been discussed the possibility to enforce view and parameters?

Let's say we had a setting called for example only allow read using view.
This setting would block any form of read access except when using a view.

Then we could inside a view enforce different parameters and
throw exceptions on illegal or missing parameters.

Today we have validate_doc_update, so if we added validate_doc_read, we
could use the validate_doc_read to validate call to the view.

We have a set of documents with a field called customernumber.
We have a user with field called customernumbers (for example: 1, 2, 3)

When the view is called it would call the validate_doc_read function. Inside
this function we could add for example add this: doc.customernumber == 1
|| doc.customernumber == 2 || doc.customernumber == 3 (this would be done
through a loop getting  values from the users customernumbers). This way we
enforce the query to only query for documents with customernumber equal to
one of user's customer numbers.

This way the view will work as it does today, except that more filters is
added by the validate_doc_read function. Reduce functions will work as they
do today. Replication would not be affected. Caching may be affected and
some performance impact off course but adding more security without any form
of performance impact is almost impossible.
To get even more security you could inside the validate_doc_read function
add a check for allowed_views (field added to user). If the user do not have
the accessed view in his allowed_views array we would throw an exception.

By doing this we would get read access control pr document. Off course this
would not cover all security scenarios but I think this would cover enough
since CouchDB are not meant to solve every possible database scenario.

What are your thoughts?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message