[GitHub] [couchdb] wa0nder opened a new issue #3079: Per-user Database document access control

[GitBox <gi...@apache.org>]

wa0nder opened a new issue #3079:
URL: https://github.com/apache/couchdb/issues/3079


   [NOTE]: # ( ^^ Provide a general summary of the request in the title above. ^^ )
   Determine which documents and document fields are returned by a GET request applying a process virtually identical to 'validate_doc_update' functions. 
   
   ## Summary
   
   [NOTE]: # ( Provide a brief overview of what the new feature is all about. )
   Disclaimer: I have already seen the various opened issues about 'per document access' [here](https://github.com/apache/couchdb/issues/1524), [here](https://github.com/apache/couchdb/issues/1891) and [here](https://github.com/apache/couchdb/issues/1504) and this isn't the same as those, at least as far as I can tell.
   
   What I have in mind is to apply a validate function to not only PUT requests as done currently but also to GET requests to allow individual db users to completely control which documents and which part of those documents they want to share.
   
   ## Desired Behaviour
   
   [NOTE]: # ( Tell us how the new feature should work. Be specific. )
   [TIP]:  # ( Do NOT give us access or passwords to your actual CouchDB! )
   When a GET request is made, CouchDB looks for a 'validate_doc_request' (VDR) function (similarly to a 'validate_doc_update' function) and, if it exists, the requested document is passed to it. Whatever the VDR returns due to filtering/restriction code is what is sent to the requesting client.
   
   ## Possible Solution
   
   [NOTE]: # ( Not required. Suggest how to implement the addition or change. )
   When a PUT request with a document is made, a 'validate_doc_update' (VDU) function is called to apply restrictions, filtering, etc. In the same way, when a GET request for a specific document is made, run a 'validate_doc_request' (VDR) function.
   
   CouchDB would grab the requested document and send it to the VDR which would be able to apply filtering, restrictions, conditional statements, security object considerations, etc. and return only a subset (or empty) of that document along with the '_id' and '_rev' fields. 
   
   All returned fields would contain a path from root to 'position in document' in order to keep track of where data subsets originated in the document.  
   
   After a user modifies the returned document and sends it back, CouchDB would run a 'merge subset with parent document' function before sending to VDU for validation. That's all.
   
   Here's a quick example to demonstrate.
   1. Sample document in DB:
   ```
   {
     _id: 'testDoc',
     _rev: ....,
     field1: {
       field1_a: {
         name: 'bo'
       }
     },
     field2: ...
   }
   ```
   
   2. Let's pretend that after some VDR runs it spits out:
   ```
   {
     _id: 'testDoc',
     _rev: ....,
     field1_a: {
       path: 'field1/',
       value: { name: 'bo' }
     }
   }
   ```
   
   3. After user modification client-side some fields are added:
   ```
   {
     _id: 'testDoc',
     _rev: ....,
     field1_a: {
       path: 'field1/',
       value: { name: 'jane', field1_a_1: [...] }
     }
   }
   ```
   
   4. After submission back to CouchDB and the merge function is run:
   ```
   {
     _id: 'testDoc',
     _rev: ....,
     field1: {
       field1_a: {
         name: 'jane',
         field1_a_1: [...]
       }
     },
     field2: ...
   }
   ```
   
   5. Now the VDU will be sent the original doc as 'oldDoc' and this merged doc as 'newDoc'. Everything else proceeds as normal. For security reasons, if a returned 'path' cannot be matched in the original doc then that value will be ignored.
   
   That's it. Please let me know if I need to clarify further. Also, if this is infeasible for "behind the scenes" Erlang restrictions and/or CouchDB architectural reasons let me know and I can remove this proposal. Thanks!
   
   ## Additional context
   
   [TIP]:  # ( Why does this feature matter to you? What unique circumstances do you have? )
   Despite no longer being recommended from a development perspective, I'm still interested in the two-tier stack idea of CouchDB and what sorts of applications can be created by making the most of the built-in server capabilities.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [couchdb] wohali closed issue #3079: Per-user Database document access control

[GitBox <gi...@apache.org>]

wohali closed issue #3079:
URL: https://github.com/apache/couchdb/issues/3079


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org