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:25:49 GMT

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

> 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.

No, I mean in my scenario the person who could make a local change to a doc
they didn’t create would *NOT* have the replicator user’s credentials, so
they could NOT replicate things back elsewhere.

You point is important though: you need to set these things up carefully :)

Best
Jan
-- 




Mime
View raw message