couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Capturing UserCtx automatically
Date Wed, 19 Feb 2014 13:15:25 GMT

On 19 Feb 2014, at 13:27 , Alexander Shorin <kxepal@gmail.com> wrote:

> On Wed, Feb 19, 2014 at 4:17 PM, Jan Lehnardt <jan@apache.org> wrote:
>> On 19 Feb 2014, at 13:02 , Alexander Shorin <kxepal@gmail.com> wrote:
>> 
>>> On Wed, Feb 19, 2014 at 3:59 PM, Jan Lehnardt <jan@apache.org> wrote:
>>>> On 19 Feb 2014, at 11:42 , Alexander Shorin <kxepal@gmail.com> wrote:
>>>> 
>>>>> On Wed, Feb 19, 2014 at 2:24 PM, Robert Samuel Newson
>>>>> <rnewson@apache.org> wrote:
>>>>>> validate_doc_update(oldDoc, newDoc, userCtx) {
>>>>>> 
>>>>>> if (newDoc.audit_trail[0].user != userCtx.name) {
>>>>>> throw({forbidden: "You didn’t add your name to the audit trail!"});
>>>>>> }
>>>>>> …
>>>>>> }
>>>>> 
>>>>> There is one issue with such approach: replications. You will not be
>>>>> able to replicate documents which has different username in
>>>>> audit_trail from those one who runs the replication. Or, to be more
>>>>> detailed, you'll replicate fine all documents till the design document
>>>>> which brings this validation function to your database and after that
>>>>> you'll only able to store documents which matches replication's user.
>>>> 
>>>> You could add the replication user to the validation function and keep
>>>> the original author.
>>> 
>>> Sure, I could. But this would be tricky and unclear for other users
>>> that just wanted to grab the data from CouchDB.
>> 
>> how so?
> 
> Let's say we have some database where multiple users are collaborating
> upon some stuff. Let it be image hosting service based on CouchDB
> where friends shares images between. Your users allowed to post new
> docs with images, but they don't wanted to see how others users
> changes docs that they owned. We forbidden such actions via
> validate_doc_update function by checking if doc.author matches
> userCtx.name. So, that's the case: you allowed to update own documents
> and only allow to read the others.
> 
> Now some user wanted to replicate this database to local CouchDB. He
> already has his own personal credentials. And he'll use them in
> replication and I wonder if he's able to recall another account to use
> for replications. Also, if I create special username which is able to
> bypass validation function ... well, that's a bug in the system -
> what's the reason left to use restricted accounts when you have access
> to more powerful ones?

In this scenario, the other user would not be able to invoke a replication
with the replication-user credentials.


Mime
View raw message