arturog commented on PR #4673: URL: https://github.com/apache/couchdb/pull/4673#issuecomment-1709893420
I am coming back to couchdb updating an old application that *has already* implemented the above (per-document access, with linux-like permissions like owner/read/write access, even per-field protection on the doc). I personally don't like this feature and wouldn't like to see it merged: - This kind of security requirement is almost always specific to the application. In my case, for example, this solution is not fit for purpose. - Most of the time a front-end application server is better suited to handle security requirements, which might be complex. - I believe CouchDB should stick to being a database. We should refine the current codebase instead. - If we need to implement this kind of functionality (like in my case), we are better off providing a plugin/hook system where can enter the validate and read lifecycle of the document. Devs are free to implement what they want and we could provide a working example. (This is what *I* did). Providing a `_custom_<field>` on documents for devs to freely use would be great. - Are we going to filter the views? Are we going to filter the document counts on views? What about leaking information on views? Some views need some info, some others not? Will I sometimes use per-user view, sometimes the global views? And what about searching with Lucene? I feel we should not touch our indices. - Replicating documents *into* your database where the _access field changes, are we doing that? Will devs want a "master" where the `_access` field is allowed to change, and slaves where you won't? Is the ultimate purpose of this PR to segregate documents within your own DB? Then why not create per-user DBs? I would be in favour of document lifecycle plugins/hooks, where we can implement this feature and many others. -- 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. To unsubscribe, e-mail: notifications-unsubscr...@couchdb.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
