couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: proposal: Using the db hooks in other databases
Date Wed, 04 Jan 2012 22:11:20 GMT
On Wed, Jan 4, 2012 at 05:52, Benoit Chesneau <bchesneau@gmail.com> wrote:
> I've put a more readable and updated version here :
>
> https://github.com/refuge/refuge/wiki/DB-Security-hooks
>
> On Wed, Jan 4, 2012 at 10:52 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> Hi all,
>>
>> Following is a quick proposal to implement support of hooks to other
>> databases. Let me know what you think about it. I would be be happy to
>> start the work on that.

Thanks for getting this conversation going. I support the idea. You
and I discussed a database erlang behaviour and IIRC you did some work
on it. Did you go further? I wonder if a default behaviour is to
delegate to design docs and if any common behaviour module could
simplify code for _users, _replicator, and _design-based.

I am already getting too into implementation, though. +1 on the overall idea.

-Randall

>>
>> - benoît
>>
>>
>> # Using the db hooks in other databases
>>
>> ## Definitons
>>
>> Hooks
>>  `before_doc_update` & `after_doc_read` functions that could be
>> associated to a db object.
>>
>> Db
>>  abbreviation of database.
>>
>> ## Goal
>>
>> Today the db hooks are only used in the `_users` & `_replicator` dbs. It
>> would be good to generalize them to other dbs. Ie. an admin should be
>> abble to add these functions on any created dbs.
>>
>> ## Possible solutions
>>
>> ### In the design documents
>>
>> We could like the validate_doc_update function, add such function to any
>> design documents. Function would be :
>>
>>
>>    function before_doc_update(Doc, UserCtx, SecObj) {
>>
>>    }
>>
>>
>>    function after_doc_read(Doc, UserCtx, SecObj) {
>>
>>    }
>>
>>
>> Then this functions will be processed in a loop. Processed functions
>> could return:
>>
>> - `true` if nothing is changed
>> - a new doc or the doc  object
>> - an error witch will be raised.
>>
>>
>> While the `after_read_doc` coulc return
>>
>>
>> ### In the security object.
>>
>> Historically the `validate_doc_update` function is in the the design
>> document. But such functions could also be in the security object. The
>> above solution has the advantage to not change the way couchdb already
>> work.
>>
>>
>> ## Optimisations
>>
>> - on_changes & all_docs hooks. Actually these hooks are hardcoded in
>>  couch. We should change that to allow anyone to build its own security
>> system.
>>
>> - If in JS, such functions should support the commonjs `require`
>>  feature.
>>
>>
>> ## Example
>>
>> ### Dropbox
>>
>> One usecase of such feature would allows to easily add a dropbox feature
>> to couch. In tis scenarion any user can drop a document, but only admins
>> can read it. It could be done by these functions:
>>
>>
>>    function after_doc_read(Doc, UserCtx, SecObj) {
>>        if (userCtx.roles.find("_admin") == -1)
>>            return {"forbidden": "you don't can't read docs in this
>> db"};
>>        }
>>    }
>>
>> Here we also need an `on_all_docs` function:
>>
>>    function on_all_docs(UserCtx, SecObjc) {
>>        if (userCtx.roles.find("_admin") == -1)
>>            return {"forbidden": "you don't can't read docs in this
>> db"};
>>        }
>>    }
>>
>>
>> and an `on_changes` function:
>>
>>    function on_all_docs(UserCtx, SecObjc) {
>>        if (userCtx.roles.find("_admin") == -1)
>>            return {"forbidden": "you don't can't read docs in this
>> db"};
>>        }
>>    }
>>
>>> **Note:** These functions could of course be in Erlang.

Mime
View raw message