couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Capturing UserCtx automatically
Date Wed, 19 Feb 2014 13:19:42 GMT
On Wed, Feb 19, 2014 at 5:15 PM, Jan Lehnardt <jan@apache.org> wrote:
> 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.

Which bypassed validation rules, right? And what stops him to use the
same credentials to push data back from local instance to public one?
If it workarounds validation rules, he'll be able to rewrite docs that
he shouldn't be able to. That's the problem.

--
,,,^..^,,,

Mime
View raw message