You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by max <ma...@gmail.com> on 2017/01/13 14:15:51 UTC

_users overwritte _design/_auth

Hi,
I need to allow some users to delete other users without being a CouchDB
Administrator. To do that I updated _users/_design/_auth to change the
'_admin' check to:
if ((userCtx.roles.indexOf('_admin') !== -1) ||
(userCtx.roles.indexOf('manager') !== -1 &&
userCtx.roles.indexOf(oldDoc.databases[0]) !== -1) ||
            (userCtx.name == oldDoc.name)) {
            return;
        } else {
            throw ({
                forbidden: 'Only admins may delete other user docs.'
            });
        }
It works but sometimes CouchDB reset this _design/_auth document. I've read
in doc this design doc cannot be modified but I couldn't find another way
to achieve this.
Is there a way to prevent CouchDB to do that ?  Or another way to do what
I'm trying to do ?
I'm using CouchDB 1.4.

Thanks.

Max.

Re: _users overwritte _design/_auth

Posted by Jan Lehnardt <ja...@apache.org>.
Hi,

CouchDB natively can't do what you want and it's by design. Not saying it's good design, it's just what it is.

You could have a small daemon that your non-admin users can notify to do. user deletions, and hat daemon then gets server admin permissions.

Cheers
Jan
--

> On 13 Jan 2017, at 20:59, max <ma...@gmail.com> wrote:
> 
> Hi,
> 
> Thank you for your answer ! I'll give it a try but I was expecting a native
> issue. Let's see if someone else have already faced this problem. I'd be
> suprised if it was not supported.
> 
> Max.
> 
> Le 13 janv. 2017 5:51 PM, "Martin Broerse" <ma...@gmail.com> a
> écrit :
> 
>> Hi Max,
>> 
>> I am thinking about doing something similar with openWhisk. You can create
>> a "users-to-delete" database only some users can write usernames to. On
>> change to this database an openWhisk Action can delete the usernames
>> specified in this "users-to-delete" database with full admin rights and
>> remove the usernames on success.
>> 
>> Just my 2 cents.
>> 
>> - Martin
>> 
>>> On Fri, Jan 13, 2017 at 3:15 PM, max <ma...@gmail.com> wrote:
>>> 
>>> Hi,
>>> I need to allow some users to delete other users without being a CouchDB
>>> Administrator. To do that I updated _users/_design/_auth to change the
>>> '_admin' check to:
>>> if ((userCtx.roles.indexOf('_admin') !== -1) ||
>>> (userCtx.roles.indexOf('manager') !== -1 &&
>>> userCtx.roles.indexOf(oldDoc.databases[0]) !== -1) ||
>>>            (userCtx.name == oldDoc.name)) {
>>>            return;
>>>        } else {
>>>            throw ({
>>>                forbidden: 'Only admins may delete other user docs.'
>>>            });
>>>        }
>>> It works but sometimes CouchDB reset this _design/_auth document. I've
>> read
>>> in doc this design doc cannot be modified but I couldn't find another way
>>> to achieve this.
>>> Is there a way to prevent CouchDB to do that ?  Or another way to do what
>>> I'm trying to do ?
>>> I'm using CouchDB 1.4.
>>> 
>>> Thanks.
>>> 
>>> Max.
>>> 
>> 


Re: _users overwritte _design/_auth

Posted by max <ma...@gmail.com>.
Hi,

Thank you for your answer ! I'll give it a try but I was expecting a native
issue. Let's see if someone else have already faced this problem. I'd be
suprised if it was not supported.

Max.

Le 13 janv. 2017 5:51 PM, "Martin Broerse" <ma...@gmail.com> a
écrit :

> Hi Max,
>
> I am thinking about doing something similar with openWhisk. You can create
> a "users-to-delete" database only some users can write usernames to. On
> change to this database an openWhisk Action can delete the usernames
> specified in this "users-to-delete" database with full admin rights and
> remove the usernames on success.
>
> Just my 2 cents.
>
> - Martin
>
> On Fri, Jan 13, 2017 at 3:15 PM, max <ma...@gmail.com> wrote:
>
> > Hi,
> > I need to allow some users to delete other users without being a CouchDB
> > Administrator. To do that I updated _users/_design/_auth to change the
> > '_admin' check to:
> > if ((userCtx.roles.indexOf('_admin') !== -1) ||
> > (userCtx.roles.indexOf('manager') !== -1 &&
> > userCtx.roles.indexOf(oldDoc.databases[0]) !== -1) ||
> >             (userCtx.name == oldDoc.name)) {
> >             return;
> >         } else {
> >             throw ({
> >                 forbidden: 'Only admins may delete other user docs.'
> >             });
> >         }
> > It works but sometimes CouchDB reset this _design/_auth document. I've
> read
> > in doc this design doc cannot be modified but I couldn't find another way
> > to achieve this.
> > Is there a way to prevent CouchDB to do that ?  Or another way to do what
> > I'm trying to do ?
> > I'm using CouchDB 1.4.
> >
> > Thanks.
> >
> > Max.
> >
>

Re: _users overwritte _design/_auth

Posted by Martin Broerse <ma...@gmail.com>.
Hi Max,

I am thinking about doing something similar with openWhisk. You can create
a "users-to-delete" database only some users can write usernames to. On
change to this database an openWhisk Action can delete the usernames
specified in this "users-to-delete" database with full admin rights and
remove the usernames on success.

Just my 2 cents.

- Martin

On Fri, Jan 13, 2017 at 3:15 PM, max <ma...@gmail.com> wrote:

> Hi,
> I need to allow some users to delete other users without being a CouchDB
> Administrator. To do that I updated _users/_design/_auth to change the
> '_admin' check to:
> if ((userCtx.roles.indexOf('_admin') !== -1) ||
> (userCtx.roles.indexOf('manager') !== -1 &&
> userCtx.roles.indexOf(oldDoc.databases[0]) !== -1) ||
>             (userCtx.name == oldDoc.name)) {
>             return;
>         } else {
>             throw ({
>                 forbidden: 'Only admins may delete other user docs.'
>             });
>         }
> It works but sometimes CouchDB reset this _design/_auth document. I've read
> in doc this design doc cannot be modified but I couldn't find another way
> to achieve this.
> Is there a way to prevent CouchDB to do that ?  Or another way to do what
> I'm trying to do ?
> I'm using CouchDB 1.4.
>
> Thanks.
>
> Max.
>